Фрагментація DNS EDNS0: прихована причина «працює по Wi‑Fi, не працює по LTE»

Що таке фрагментація EDNS0 насправді (і чому LTE — ідеальний «злодій»)

DNS народився з UDP‑відповідями, обмеженими 512 байтами. Це було не «гарним доповненням», це було питання виживання.
Малі пакети означають менше фрагментації, менше повторних передач, менше несподіванок. Потім інтернет розширився:
більше записів в одній відповіді, більше glue, IPv6, підписи DNSSEC і бажання не переводити все на TCP.

EDNS0 (Extension Mechanisms for DNS) — це компроміс. Клієнт (резолвер) каже: «Я можу приймати UDP‑відповіді до N байт».
Сервер намагається вкластися. Якщо не виходить — він ставить біт TC (транкованість) і клієнт повторює запит по TCP.
На папері це елегантно. В реальних мережах «папір» в дефіциті.

Пастка: коли ви рекламуватимете великий UDP‑розмір (зазвичай 1232, 1400, 4096), ви запрошуєте великі UDP‑відповіді.
Великі UDP‑відповіді часто перевищують MTU шляху і фрагментуються на рівні IP.
Фрагментація означає: одна відповідь DNS перетворюється на кілька IP‑пакетів, які всі повинні дійти і бути зібраними.
Якщо втрачається один фрагмент — вся відповідь DNS розчиняється.

Багато мобільних і «middlebox‑насичених» мереж алергічні до фрагментів. Деякі просто скидають фрагменти за задумом.
Деякі обробляють їх неправильно. Деякі збирають некоректно. Деякі обмежують їх по швидкості до невпізнання.
Wi‑Fi‑шляхи — особливо в корпоративних мережах або домашньому бродбенді —, як правило, більш поблажливі або принаймні послідовні.
Шляхи LTE — це смуга перешкод з NAT, файрволів, оптимізаторів трафіку й політик. Суть в тому: LTE не «гірший»,
він просто складніший.

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

Жарт №1: UDP‑фрагментація — це як надсилати порцелянову кружку в двох конвертах — технічно можливо, емоційно безвідповідально.

Механіка простими словами

• Клієнт відправляє DNS‑запит (UDP) з записом EDNS0 OPT, вказуючи «я можу прийняти X байт».
• Сервер відповідає (UDP), намагаючись вкластися в X байт.
• Якщо відповідь все одно не вміщується — сервер встановлює TC=1 (транковано) і клієнт має повторити по TCP.
• Якщо відповідь вміщується в X, але перевищує MTU шляху, IP‑рівень її фрагментує.
• Якщо фрагменти відкидають, затримують або фільтрують — клієнт бачить таймаут, не обовʼязково TC.

Чому «великий UDP» привабливий

Оператори люблять ідею уникнути TCP для DNS: менше зʼєднань, менше стану, нижче затримки під навантаженням.
Деякі резолвери й авторитетні сервери навіть за замовчуванням вказують «щедрі» EDNS‑розміри, бо в чистих лабораторіях це дає хороші бенчмарки.
Потім настають реальні мережі. Особливо мобільні. Особливо при роумінгу. Особливо через VPN‑тунелі.

Чому працює по Wi‑Fi, але не по LTE

Найпростіша модель розуміння: користувачі Wi‑Fi часто сидять за одним NAT зі стабільним MTU і меншою кількістю «помічників пакета».
Користувачі LTE знаходяться за carrier‑grade NAT, часто за кількома шарами політик і іноді з дивними MTU.
Додайте механізми переходу IPv6, тунелі і «оптимізатори», і фрагменти стають підозрілими.

Поширені особливості шляху LTE, що ламають фрагментований UDP

• Carrier‑grade NAT (CGNAT), який має обмеження на обробку фрагментів або агресивні таймаути.
• Політики файрвола, що відкидають непочаткові фрагменти через складність класифікації.
• Формування трафіку, яке знижує пріоритет або лімітує фрагменти (іноді ненавмисно).
• Змінність PMTU через роумінг або тунельні бекхоли.
• Переклад IPv6/IPv4, де обробка фрагментів відрізняється між стеком або містить баги.

Невідповідність «EDNS0 розмір vs MTU»

Припустимо, ваш резолвер рекламує EDNS0 UDP‑розмір 4096. Ваш авторитетний сервер охоче відповідає 1800‑байтовим UDP‑пакетом.
Цей 1800‑байтовий IP‑пейлоад не вміщується в типовий 1500‑байтовий Ethernet MTU після заголовків. Виникає фрагментація.
По Wi‑Fi фрагменти доходять; по LTE другий фрагмент зникає. Клієнт бачить таймаут DNS.

Тепер припустимо, ви зменшите EDNS0 розмір до 1232. Багато відповідей падають нижче порога фрагментації.
Або сервер раніше обріже відповідь, змушуючи fallback на TCP. У будь‑якому разі ви перестаєте покладатися на крихкі фрагменти.
Ось чому 1232 стало практичним компромісом: воно достатньо консервативне, щоб уникати фрагментації на багатьох шляхах,
включно з IPv6, де заголовки більші і правила фрагментації інші.

Чому ви не завжди бачите TCP‑fallback

«Але DNS має повторюватися по TCP, якщо UDP не вдалося». Теоретично так.
На практиці:

• Деякі клієнти повільно переходять на fallback, так що користувач бачить «зависання, потім можливо завантажиться».
• Деякі middlebox‑и блокують DNS по TCP (порт 53) або вважають його підозрілим.
• Деякі резолвери кешують часткові збої, підсилюючи проблему на кілька хвилин.
• Деякі авторитетні налаштування погано працюють по TCP при сплесках fallback‑трафіку і таймаутяться.

Помилки фрагментації EDNS0 ламають не лише UDP. Вони можуть загнати вас у патерн TCP‑навантаження, для якого ви не були готові.

Цікаві факти та історичний контекст (що пояснює сучасні дивності)

• Початкове обмеження UDP DNS 512 байт не було довільним стандартом; воно було створено для інтернету, де фрагментація була реальною операційною небезпекою.
• EDNS0 стандартизували наприкінці 1990‑х, щоб розширити DNS без зміни основного формату повідомлення, використовуючи псевдо‑запис OPT.
• DNSSEC зробив «великі відповіді» звичайними через додавання підписів (RRSIG), ключів (DNSKEY) і доказів відсутності (NSEC/NSEC3).
• Міф «більше — швидше» зʼявився, коли деякі резолвери за замовчуванням ставили великі EDNS буфери, щоб зменшити TCP‑fallback у бенчмарках.
• IPv6 змінив правила фрагментації: маршрутизатори не фрагментують; це роблять лише кінцеві точки, тому PMTU‑виявлення й розмір пакетів важливіші.
• Деякі старі файрволи за замовчуванням відкидають фрагменти, бо непочаткові фрагменти не містять L4‑заголовків і ускладнюють фільтрацію.
• CDN і багатозаписні відповіді збільшили розмір відповідей: множинні A/AAAA, ECS варіації та додаткові glue можуть роздути відповіді.
• EDNS Client Subnet (ECS) може змінити розмір відповіді та поведінку кешування, інколи штовхаючи відповіді через порог фрагментації несподівано.
• «DNS по TCP існує не просто так»: навіть ранні специфікації DNS включали TCP як надійну резервну опцію, але багато операторів вважали його «рідкісним».

Сигнатури відмов, які ви можете впізнати за хвилини

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

Класичні симптоми

• По Wi‑Fi працює, по LTE — не працює (або працює в одного оператора, не працює в іншого).
• Запити AAAA частіше падають ніж A через більший розмір відповіді або відмінності MTU по IPv6.
• Помилки валідації DNSSEC на конкретних доменах, часто випадкові та залежні від географії.
• Великі TXT‑записи (SPF, DKIM, токени підтвердження) викликають збої лише для частини користувачів.
• Авторитетні сервери виглядають здоровими; обʼєм запитів нормальний; але логи на клієнтах показують SERVFAIL або таймаути.
• Пакетні захоплення показують вихідні відповіді без відповідних вхідних підтверджень/повторів, бо UDP не ACK; ви робите висновок про втрати по повторних запитах.

Що ви фактично спостерігаєте

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

«перефразована ідея» від Richard Cook (safety/ops): системи відмовляють у несподіваних способах, бо для успіху потрібно, щоб багато речей спрацювали, а для відмови достатньо одного збою.

План швидкої діагностики

Не починайте з дискусій про DNS‑сервери. Спочатку доведіть, чи ви втрачаєте фрагменти або чи примушуєте транкацію.
Мета — звузити проблему до одного речення, за яким можна діяти: «Великі UDP‑відповіді гинуть на LTE‑шляху».

По‑перше: підтвердьте, що це розмір/транспорт, а не «неправильні записи»

1. Порівняйте той самий запит по двох мережах (Wi‑Fi vs LTE) використовуючи той самий резолвер, якщо можливо.
2. Примусово зменште EDNS0 розміри і подивіться, чи зникають збої.
3. Примусово використайте TCP і перевірте, чи зникають збої (або чи TCP блокується).

По‑друге: визначте, де саме розрив

1. Stub‑резолвер клієнта vs рекурсивний: чи працює прямий запит до рекурсивного?
2. Рекурсивний vs авторитетний: чи не падає рекурсивний лише при зверненні до певних авторитетів?
3. Пограничні пристрої: чи є у вас файрвол, балансувальник або DDoS‑пристрій перед авторитетним DNS?

По‑третє: застосуйте найменш ризикове помʼякшення

1. Зменшіть оголошений EDNS0 UDP‑розмір на рекурсивних резолверах (часто до 1232).
2. Переконайтеся, що TCP/53 працює наскрізь (рекурсивний → авторитетний, і клієнти → рекурсивний, залежно від архітектури).
3. Уникайте надмірних відповідей: обріжте TXT‑багатозаписи, зменшіть непотрібні записи, розгляньте формування відповідей при DNSSEC.

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

Завдання 1: Виміряйте розмір відповіді і перевірте ризик фрагментації

cr0x@server:~$ dig example.com A +dnssec +bufsize=4096 @8.8.8.8

; <<>> DiG 9.18.24 <<>> example.com A +dnssec +bufsize=4096 @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14651
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      A

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

;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; MSG SIZE  rcvd: 97

Що це означає: MSG SIZE rcvd тут крихітний, тому фрагментація не ваша проблема для цього запиту.
Рішення: Тестуйте домени/типи записів, що падають (TXT, DNSKEY, великі CNAME‑ланцюги), а не простий A‑запит.

Завдання 2: Протестуйте відомий «великий» запис (TXT) з великим EDNS0 буфером

cr0x@server:~$ dig example.com TXT +bufsize=4096 @1.1.1.1

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53204
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      TXT

;; ANSWER SECTION:
example.com.            3600    IN      TXT     "v=spf1 -all"
example.com.            3600    IN      TXT     "some-long-verification-token=..."
example.com.            3600    IN      TXT     "another-token=..."

;; Query time: 31 msec
;; MSG SIZE  rcvd: 1605

Що це означає: 1605 байт по UDP ймовірно фрагментуються на багатьох шляхах з MTU 1500.
Рішення: Повторно протестуйте з меншими EDNS0 розмірами і по TCP, щоб підтвердити чутливість до розміру.

Завдання 3: Примусити консервативний EDNS0 розмір, щоб уникнути фрагментації

cr0x@server:~$ dig example.com TXT +bufsize=1232 @1.1.1.1

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60421
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com.                   IN      TXT

;; ANSWER SECTION:
example.com.            3600    IN      TXT     "v=spf1 -all"
example.com.            3600    IN      TXT     "some-long-verification-token=..."

;; Query time: 29 msec
;; MSG SIZE  rcvd: 812

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

Завдання 4: Виявити транкацію (біт TC) і перевірити, чи має відбуватися TCP‑повтор

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

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3122
;; flags: qr rd ra tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: Message has been truncated
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com.                   IN      DNSKEY

;; Query time: 35 msec
;; MSG SIZE  rcvd: 512

Що це означає: tc встановлено; UDP‑відповідь не вмістилася. Повинен бути повтор по TCP.
Рішення: Якщо клієнти все одно падають — перевірте, чи не блокується TCP/53 або чи авторитетний сервер коректно обробляє TCP.

Завдання 5: Примусово TCP і перевірити, чи зникає «LTE‑помилка»

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

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61752
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;example.com.                   IN      DNSKEY

;; ANSWER SECTION:
example.com.            3600    IN      DNSKEY  257 3 13 ...
example.com.            3600    IN      DNSKEY  256 3 13 ...

;; Query time: 44 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (TCP)
;; MSG SIZE  rcvd: 1203

Що це означає: TCP працює і повертає більший пейлоад надійно.
Рішення: Якщо TCP працює скрізь, але UDP падає на LTE — помʼякшіть шлях, зменшивши UDP‑розміри і забезпечивши доступність TCP.

Завдання 6: Перевірте, чи ваш рекурсивний резолвер рекламуватиме агресивний EDNS‑розмір

cr0x@server:~$ dig whoami.akamai.net TXT +bufsize=4096 @10.0.0.53

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;whoami.akamai.net.            IN      TXT
;; ANSWER SECTION:
whoami.akamai.net.     20      IN      TXT     "198.51.100.17"
;; MSG SIZE  rcvd: 128

Що це означає: Ваш резолвер (10.0.0.53) готовий приймати 4096‑байтові UDP‑відповіді від upstream‑авторитетів.
Рішення: Розгляньте зниження до 1232, якщо немає обґрунтованої причини для великого розміру.

Завдання 7: Перевірте транкацію і повтори в логах Unbound

cr0x@server:~$ sudo journalctl -u unbound --since "1 hour ago" | egrep -i "trunc|tc|timeout" | tail -n 8
[12234:0] info: response was truncated, retrying with TCP
[12234:0] info: tcp connected to 203.0.113.53 port 53
[12234:0] info: tcp returned answer for example.com. DNSKEY IN
[12234:0] info: resolving example.com. TXT IN: query response was truncated
[12234:0] info: tcp error: connection timed out
[12234:0] info: validation failure <example.com. DNSKEY IN>: no DNSKEY rrset

Що це означає: Ви бачите транкацію і спроби TCP‑fallback; одне TCP‑зʼєднання таймаутило.
Рішення: Дослідіть доступність TCP/53 до конкретних авторитетів і наявність middlebox‑ів між рекурсивом і інтернетом.

Завдання 8: Переконайтеся, що TCP/53 досяжний з рекурсиву до авторитетного

cr0x@server:~$ nc -vz 203.0.113.53 53
Connection to 203.0.113.53 53 port [tcp/domain] succeeded!

Що це означає: TCP/53 до цього сервера досяжний з цього хоста.
Рішення: Якщо це падає для деяких авторитетів — виправте правила файрвола/egress або використайте резолвер, що може дістатися по TCP.

Завдання 9: Захопіть фрагменти на рекурсивному резолвері і доведіть, що вони є

cr0x@server:~$ sudo tcpdump -ni eth0 'udp port 53 and (ip[6:2] & 0x1fff != 0)' -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:03:21.112233 IP 198.51.100.10.53 > 10.0.0.53.49321: UDP, length 1472
14:03:21.112240 IP 198.51.100.10 > 10.0.0.53: ip-proto-17
14:03:21.112245 IP 198.51.100.10 > 10.0.0.53: ip-proto-17
5 packets captured

Що це означає: Фільтр спрацював на фрагментований UDP (не‑нульовий зсув фрагменту або MF‑флаг). Ви бачите фрагменти.
Рішення: Якщо клієнти по LTE падають і ви спостерігаєте фрагментацію на шляху — зменшіть EDNS‑розміри і віддайте перевагу TCP‑fallback.

Завдання 10: Перевірте ICMP, повʼязаний з PMTU (частий мовчазний співучасник)

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

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Що це означає: Десь у вас MTU = 1492 (PPPoE — типовий підозрюваний), отже «безпечні» пейлоади менші.
Рішення: Вважайте 1232 базовим параметром і підозрюйте все, що регулярно штовхає UDP‑відповіді вище ~1200 байт.

Завдання 11: Перегляньте правила iptables/nftables, що можуть скидати фрагменти

cr0x@server:~$ sudo iptables -S | egrep -i "fragment|frag|DROP" | head
-A INPUT -f -j DROP
-A FORWARD -f -j DROP

Що це означає: «-f» відповідає за фрагменти; ви їх відкидаєте. Це не «безпека», це само‑саботаж для UDP‑протоколів.
Рішення: Припиніть відкидати фрагменти навмання на шляхах, що обслуговують DNS; замість цього зменшіть EDNS‑розмір і дозволіть TCP.

Завдання 12: Переконайтесь, що ваш авторитетний DNS відповідає по TCP (деякі цього не роблять, поки ви не спитаєте)

cr0x@server:~$ dig yourzone.example DNSKEY +tcp @ns1.yourauth.example

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40422
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; SERVER: 192.0.2.53#53(192.0.2.53) (TCP)
;; MSG SIZE  rcvd: 1890

Що це означає: TCP працює і повертає велику відповідь.
Рішення: Якщо TCP тут падає — виправте підтримку TCP на авторитеті перш ніж «тонувати EDNS» деінде.

Завдання 13: В BIND перевірте поточні EDNS та TCP‑налаштування (авторитетний або рекурсивний)

cr0x@server:~$ sudo named-checkconf -p | egrep -i "edns|tcp|max-udp-size|clients-per-query|tcp-clients" | head -n 20
tcp-clients 100;
clients-per-query 10;
max-udp-size 4096;

Що це означає: max-udp-size 4096 створює предпосилку для фрагментації на реальних шляхах.
Рішення: Розгляньте зменшення max-udp-size (або еквівалента) і переконайтеся, що tcp-clients вистачає для пікових fallback‑ів.

Завдання 14: В Unbound підтвердіть EDNS‑буфер і налаштуйте безпечно

cr0x@server:~$ sudo unbound-checkconf | egrep -i "edns-buffer-size|so-rcvbuf|so-sndbuf|tcp-upstream|do-tcp" || true
edns-buffer-size: 4096

Що це означає: Unbound рекламує 4096 upstream. Це часто занадто оптимістично в середовищах з великою долею мобільного трафіку.
Рішення: Встановіть edns-buffer-size на 1232, потім моніторте частоту TCP‑запитів і затримки.

Завдання 15: Доведіть, що зміна EDNS‑розміру змінює поведінку до того самого авторитетного

cr0x@server:~$ dig bigdns.example TXT +bufsize=4096 @ns.bigauth.example
;; Query time: 1200 msec
;; connection timed out; no servers could be reached

cr0x@server:~$ dig bigdns.example TXT +bufsize=1232 @ns.bigauth.example
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2211
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 48 msec
;; MSG SIZE  rcvd: 1198

Що це означає: Той самий сервер, той самий запис; змінився лише EDNS‑розмір. Один раз таймаут, інший — успіх.
Рішення: Це ваш «документальний» доказ: фрагментація або нетерпимість middlebox‑а на шляху.

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

Міні‑історія 1: Інцидент через помилкове припущення

Компанія, назвемо її «Northwind Billing», мала акуратну архітектуру: Anycast авторитетний DNS за провайдером очищення від DDoS,
плюс популярний публічний рекурсив як запасний варіант для внутрішньої діагностики. Вони ввімкнули DNSSEC для основної зони під час рутинного виконання вимог.
Розгортання було тихим для десктопних користувачів. Мobilьні реєстрації, однак, впали.

Перше припущення було болісно людським: «Мобільні користувачі мають поганий прийом». Друге припущення було ще гіршим: «DNS — стабільна каналізація».
Підтримка повідомляла стабільний шаблон: домашній бродбенд і офісний Wi‑Fi працювали; LTE часто падав при першому завантаженні сторінки.
Інженери шукали в логах API, потім у пропусках CDN, потім у TLS‑телеметрії. Все було нормальним, бо нічого не доходило до аплікації.

Прорив стався після захоплення пакетів на LTE‑хотспоті під час вікна відмови.
Відповідь DNS з DNSKEY/RRSIG була великою, фрагментованою, і другий фрагмент ніколи не дійшов.
TC‑біт не був встановлений, бо відповідь вміщалась у оголошений EDNS0 буфер; вона просто не пройшла шлях.
Рекурсив повторював; телефон користувача здавався першим. DNS «був вгору». Але він був непридатний.

Виправлення не було героїчним. Вони зменшили EDNS0 буфер на флоті рекурсивів до 1232, підтвердили, що TCP/53 дозволений,
і моніторили збільшення TCP‑запитів. Рівень відмов відразу впав.
«Помилкове припущення» було не технічним. Воно було менеджерським: ставитись до мобільних DNS‑помилок як до «випадкових», а не «залежних від шляху».

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

«Bluejay Media» працювала високонавантаженим сервісом рекурсивних резолверів для своїх додатків. Латентність там була предметом гордощів: кожен мілісекунда мала значення.
Хтось помітив, що TCP‑fallback трапляється частіше під навантаженням. Оптимізація була проста:
збільшити рекламований EDNS0 розмір, щоб більше відповідей поміщалося в UDP, менше TCP‑рухану, нижча медіанна затримка. Бенчмарки показали гарні результати.

Через два тижні почали надходити скарги від операторів: одна велика мобільна мережа мала періодичні проблеми з логінами.
Не всі. Не в усіх регіонах. Але достатньо, щоб стати кошмаром.
Дашборди показували незначне збільшення таймаутів DNS, але не настільки, щоб спрацювали алерти. Команди додатків бачили збої аутентифікації.
Сек’юріті нічого не помічала. Мережа — теж. Кожна команда бачила проблему «чужої» частини.

Відкат виявився класичним: збільшення EDNS0 перевело систему від «TC викликає TCP» до «UDP‑фрагменти повинні вижити».
В тому операторі фрагменти були обмежені по швидкості під час перевантаження. Під навантаженням резолвер розсилав фрагментовані відповіді у подрібнювач.
Повторні спроби збільшили трафік. Трафік підвищив навантаження. Навантаження підвищило відсіви. Це був не збій, а петля зворотного звʼязку.

Вони відкочували EDNS0 і — що люди часто пропускають — залишили цей відкат.
Потім правильно спланували TCP: ліміти зʼєднань, налаштування ядра і спостереження за ставкою TCP‑fallback.
Оптимізація, що «покращила медіани», виявилася регресією на надійності, прихованою у хвості затримок і в окремих мережах.

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

«Kestrel Finance» мала внутрішнє правило: кожен авторитетний DNS повинен добре підтримувати TCP, а кожна зміна в зонах проходить
«перевірку великих відповідей» в CI. Це правило існувало, бо один із старших SRE був особисто обурений поняттям втрати пакетів.
Звучало це, можливо, як перестрахування — доки не спрацювало.

Постачальник попросив додати кілька TXT‑записів підтвердження і довгий SPF‑ланцюг для нового поштового сервісу.
Зміна виглядала нешкідливо. CI її відзначив: TXT‑відповідь перевищувала 1400 байт з увімкненим DNSSEC.
Пайплайн не заблокував зміни напряму; він вимагав явного відхилення з планом помʼякшення.

План помʼякшення був нудним: розбити TXT, де можливо, прибрати застарілі токени і забезпечити, щоб рекурсивні резолвери рекламували 1232.
Також перевірили доступність TCP/53 з усіх egress‑точок їх флоту резолверів.
Зміна була впроваджена без драм, бо вони вже відрепетирували цю відмову і спроєктували навколо неї.

Порятунок не був у якомусь хитрому трюку. Це була інституціоналізована параноя: тестуйте «потворний» шлях (великі відповіді) перш ніж користувачі це зроблять,
і ставтеся до TCP як до повноцінного інструмента, а не сором’язливого fallback‑а.

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

1) «Тільки мобільні користувачі падають, десктопи в порядку» → фрагментований UDP відкидають на шляху → зменшити EDNS і впевнитися в TCP

• Симптом: таймаути DNS переважно на LTE; Wi‑Fi стабільний.
• Корінь: великі UDP‑відповіді фрагментуються; фрагменти відкидають CGNAT/файрволи.
• Виправлення: Встановіть EDNS‑буфер 1232 на рекурсивних; перевірте TCP/53; моніторте частоту TCP‑запитів.

2) «DNSSEC випадково падає валідацію» → відсутні фрагменти викликають неповні DNSKEY/RRSIG → зменшити UDP, покращити TCP, уникати розростання

• Симптом: SERVFAIL від валідуючих резолверів; випадково, залежно від оператора чи регіону.
• Корінь: відповіді DNSSEC більші; втрачаються фрагменти; валідація не проходить.
• Виправлення: Знизьте EDNS‑розмір; забезпечте відповіді по TCP; зменшуйте розмір RRset, де можливо.

3) «Ми збільшили EDNS, щоб зменшити TCP, і стало гірше» → оптимізація створила залежність від фрагментів → відкотіть EDNS, масштабувати TCP

• Симптом: менше TC, але більше таймаутів і повторів.
• Корінь: менше транкацій — менше TCP‑fallback; великі UDP тепер фрагментуються і гинуть.
• Виправлення: Віддавайте перевагу передбачуваному TCP‑fallback перед крихкою фрагментацією; плануйте потужність TCP.

4) «UDP працює, TCP падає» → middlebox блокує TCP/53 → дозволити TCP або використовувати DoT/DoH до ваших рекурсивних

• Симптом: dig працює без +tcp, але з +tcp падає, або TCP таймаутиться до авторитетів.
• Корінь: файрволи/проксі блокують або обмежують TCP/53.
• Виправлення: Виправте політику; переконайтеся, що стейт‑пристрої дозволяють TCP/53; якщо ви контролюєте клієнтів, розгляньте зашифрований DNS до довіреного резолвера.

5) «Падає лише для деяких доменів» → великі RRset, довгі TXT, багато A/AAAA, ECS варіації → обрізати і вимірювати розміри відповідей

• Симптом: падають лише певні вендори або зони.
• Корінь: розмір відповіді перетинає поріг фрагментації через великий RRset.
• Виправлення: Видаліть застарілі TXT; уникайте зайвих мультизаписів; валідуйте через dig +bufsize тести.

6) «Ми відкидаємо фрагменти заради безпеки» → ви зламали UDP‑протоколи → припиніть це (і вирішіть реальну причину)

• Симптом: випадкові UDP‑таймаути; DNS гірший при великих відповідях.
• Корінь: правила файрвола відкидають фрагменти (-f), особливо на шляхах форварду.
• Виправлення: Приберіть загальні правила відкидання фрагментів на DNS‑шляхах; використайте розумні EDNS‑розміри і TCP‑fallback.

Жарт №2: Middlebox‑и, що «оптимізують» фрагменти, як стажери, які переписують ваші runbook‑и — впевнені, швидкі і катастрофічно креативні.

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

Покроково: зупиніть відмову спочатку, потім виправляйте правильно

1. Відтворіть на шляху, що падає: використовуйте реальне LTE‑зʼєднання, а не офісний VPN, що імітує мобільний.
2. Зробіть три dig для проблемного імені:
   • за замовчуванням (те, що робить ваш резолвер)
   • +bufsize=1232
   • +tcp
3. Якщо +tcp вирішує проблему, вважайте це проблемою фрагментації/транкації до доказу зворотного.
4. Зменшіть EDNS‑буфер на рекурсивних резолверах до 1232 (або схожого консервативного значення) і впроваджуйте поступово.
5. Підтвердіть доступність TCP/53 від рекурсивів до інтернету і від клієнтів до рекурсивів (залежно від архітектури).
6. Спостерігайте за «TCP‑штурмом»:
   • кількість TCP‑зʼєднань
   • SYN‑беклог і черги прослуховування
   • латентність резолвера і таймаути
7. Обріжте надмірні DNS‑відповіді:
   • приберіть старі TXT‑токени
   • спростіть SPF, де можливо
   • уникайте зайвих мультизаписів
8. Документуйте і тестуйте: додайте «перевірку регресій великих відповідей» для критичних зон, особливо з DNSSEC.

Операційний чекліст: як має виглядати «добре»

• Рекурсивні резолвери рекламують консервативні EDNS UDP‑розміри для upstream (зазвичай 1232).
• Авторитетний DNS надійно підтримує TCP і в масштабі.
• Файрволи і балансувальники не відкидають фрагменти навмання на DNS‑шляхах.
• Моніторинг включає: частоту TC‑біта, ставку TCP‑fallback, ставку UDP‑таймаутів, SERVFAIL і телеметрію помилок по оператору (якщо є).
• У процесі змін передбачені перевірки розміру відповідей для TXT, DNSKEY і найгірших комбінацій (CNAME+DNSSEC — класика для «роздування» відповіді).

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

1) Чи сам EDNS0 «поганий»?

Ні. EDNS0 необхідний. Погано робити вигляд, що великі UDP‑пейлоади надійно доставляються через сучасні мережі,
особливо мобільні і мережі з багатьма middlebox‑ами.

2) Який EDNS0 UDP‑розмір мені використовувати?

Якщо потрібен практичний дефолт у 2025 році — 1232 є консервативним вибором, що часто дозволяє уникнути фрагментації на поширених IPv6 і IPv4 шляхах.
У контрольованих мережах можна експериментувати з більшими значеннями, але треба мати докази з продуктивних шляхів, а не лабораторних тестів.

3) Чому зменшення EDNS іноді робить відповіді «меншими», а не транкованими?

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

4) Якщо фрагментація — проблема, чому просто не «пофіксувати MTU»?

Часто цього не зробиш. Проблемний шлях може належати оператору, бути роумінговим, або користувацьким VPN‑тунелем.
Ви можете контролювати поведінку резолверів і авторитетів; навряд чи ви зможете контролювати кожне MTU між телефоном і інтернетом.

5) Чи не підвищить TCP для DNS затримки і навантаження?

Може. Але ненадійний UDP з повторними спробами і таймаутами ще гірший — особливо для UX.
Правильна стратегія: тримати UDP‑відповіді достатньо малими, щоб уникнути фрагментації, і зробити TCP надійним для випадків, коли він справді потрібен.

6) Чи можна безпечно розгортати DNSSEC, не порушивши мобільних користувачів?

Так. Але потрібно планувати збільшення розмірів відповідей, перевірити підтримку TCP, тримати RRset у нормі і не рекламувати гігантські EDNS‑розміри, що перетворюють «велике» на «фрагментоване».

7) Чому це падає тільки на одному операторі або в одній країні?

Бо middlebox‑и відрізняються. Політики обробки фрагментів різняться. MTU різні. Навіть управління заторами різне.
Проблеми фрагментації DNS за природою залежні від шляху; мінливість — ознака цього режиму відмов.

8) Чи вирішать DoH/DoT проблему фрагментації EDNS0?

Для клієнтів зашифрований DNS до рекурсивного може допомогти, бо він йде поверх TCP (або QUIC) і уникає UDP‑фрагментів на ділянці клієнт→резолвер.
Це не автоматично вирішує поведінку резолвер→авторитет; upstream все одно потребує консервативного EDNS‑розміру і доступності TCP.

9) Як дізнатися, що мій файрвол відкидає фрагменти?

Шукайте явні правила відкидання фрагментів (iptables «-f»), переглядайте лічильники і захоплення трафіку. Якщо великі UDP‑відповіді корелюють з таймаутами,
вважайте, що обробка фрагментів залучена, поки не доведете протилежне.

10) На що налаштовувати алерти, щоб ловити це рано?

Відслідковуйте зміну частоти TCP‑fallback, SERVFAIL для валідуючих резолверів, ставку UDP‑таймаутів і перцентилі затримки запитів.
Поєднайте це з телеметрією клієнтів за типом мережі (Wi‑Fi vs cellular), якщо у вас є додаток.

Висновок: кроки, що зупиняють проблему

Проблеми фрагментації EDNS0 — це ті відмови, які ви не помічаєте з серверної кімнати. Сервери відповідають. Графіки ввічливі.
Користувачі не можуть увійти, бо один з двох фрагментів не пройшов через операторський лабіринт.

Що робити, по порядку:

1. Швидко доведіть це за допомогою dig: порівняйте +bufsize=4096 vs +bufsize=1232 vs +tcp на Wi‑Fi і LTE.
2. Зробіть UDP‑відповіді меншими: тонюйте EDNS‑буфери консервативно на рекурсивних.
3. Зробіть TCP нудним і надійним: дозвольте його, масштабуйтесь під нього і моніторте.
4. Обріжте DNS‑розростання: ставтеся до TXT‑спаму і великих RRset як до боргу з відсотками.
5. Додайте регресійну перевірку для розмірів відповідей, особливо коли задіяний DNSSEC.

Виконайте ці кроки — і «працює по Wi‑Fi, не працює по LTE» знову стане мемом, а не pager‑викликом.