Ланцюги CNAME у DNS: коли вони шкодять продуктивності та надійності

Що таке ланцюг CNAME насправді (і яка його вартість)

Запис CNAME каже: «ця назва є псевдонімом для тієї іншої назви». Він не каже, де знаходиться сервіс. Він каже, хто знає, де
знаходиться сервіс.

Ланцюг CNAME виникає, коли псевдонім вказує на інший псевдонім, який вказує на ще один псевдонім тощо, поки ви
зрештою не дістанетесь адресного запису (A або AAAA) або кінцевої відповіді, наприклад NXDOMAIN.

На дошці такий ланцюг виглядає безпечним:

• api.example.com → CNAME api.edge.vendor.net
• api.edge.vendor.net → CNAME api.geo.vendor.net
• api.geo.vendor.net → A/AAAA 203.0.113.10 / 2001:db8::10

У продакшені вартість сплачується у вигляді:

• Додаткових кругових запитів (або додаткової рекурсивної роботи всередині вашого резолвера) для кожного стрибка.
• Більше точок відмов (більше зон, більше авторитарних серверів, більше крайових випадків TTL, більше політик, більше простоїв).
• Більше складності кешування (різні TTL на кожному стрибку, неоднорідна поведінка кешування між резолверами).
• Більше «працює на моєму ноутбуці» моментів (локальні резолвери, VPN-резолвери, мобільні оператори поводяться по-різному).

Універсального «поганого числа» немає, але як оператор я вважаю будь-що понад один CNAME-стрибок приводом для оцінки ризику.
Понад два стрибки — я хочу бачити причину, власника і моніторинг.

Жарт №1: Ланцюг CNAME — як внутрішнє перенаправлення дзвінка в офісі: чудово доти, поки ваш дзвінок не пройде через трьох асистентів і ніхто не знає, хто виконує роботу.

Як резольв відбувається насправді (швидко, але правильно)

З типовим stub-резолвером (хост вашого додатку) і рекурсивним резолвером (корпоративний DNS або публічний резолвер), stub запитує рекурсивного
резолвера: «що таке api.example.com?» Рекурсивний резолвер виконує переслідування: він звертається до авторитарних серверів за потреби,
слідує CNAME, перевіряє DNSSEC якщо ввімкнено, і повертає фінальні відповіді A/AAAA (і зазвичай включає ланцюг CNAME у відповіді).

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

Прихований множник: повторне використання з’єднань і промахи кеша DNS

Один DNS-запит сам по собі не має великого значення. Важить те, скільки їх ви робите, як часто у вас промахи кеша і на чому ви блокуєтесь.
Сучасні клієнти відкривають багато з’єднань (або повторно використовують їх, що краще). Коли пул з’єднань перемішується — через деплої,
автоскейлінг, таймаути NAT або скидання HTTP/2 — DNS знову опиняється на критичному шляху.

Саме тоді ланцюги CNAME перестають бути «тривією DNS» і стають фактором доступності.

Чому ланцюги CNAME шкодять продуктивності та надійності

1) Затримка: кожен стрибок додає можливості для повільних відповідей

Рекурсивний резолвер може бути змушений звертатися до кількох авторитарних серверів у різних доменах. Кожен стрибок може включати:
RTT мережі, таймери повторних спроб, відкат на TCP (коли відповіді великі), перевірку DNSSEC і обмеження по швидкості. Якщо вам не пощастить,
ви також потрапите на втрату пакетів і повторні відправлення — DNS по UDP швидкий, допоки таким не стає.

«Додатковий стрибок» не завжди означає додатковий RTT, оскільки резолвер інколи може ефективно отримати кілька записів одночасно. Але на практиці
більше стрибків означає більше зовнішніх залежностей і більше шансів перетнути межу холодного кеша.

2) Невідповідність TTL: ланцюг погано кешується

Кожен запис у ланцюгу має свій TTL. Резолвери кешують кожен RRset відповідно до його TTL. Якщо у вас є:

• довгий TTL на першому стрибку (ваша зона),
• короткий TTL на другому стрибку (зона вендора),
• і середній TTL на адресному записі,

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

3) Радіус ураження: більше зон — більше відмов

З прямим A/AAAA записом у вашій зоні ваші залежності — ваш DNS-провайдер і ваші авторитарні сервери. З ланцюгом ви також залежите від
авторитарних серверів вендора. Додайте другого вендора (CDN → WAF → GSLB) — і ви фактично побудували невелику ланцюжок поставок.

Ланцюжки поставок виходять з ладу.

4) Операційна неоднозначність: відладка стає «археологією DNS»

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

5) Поведінка, специфічна для резолвера: той самий ланцюг може поводитися по-різному

Не всі резолвери поводяться однаково. Відмінності включають:

• політику видалення з кеша та максимальний розмір кеша
• наскільки агресивно вони здійснюють попереднє отримання (prefetch)
• обмеження на глибину переслідування CNAME
• таймаути, стратегію повторних спроб та перехід UDP/TCP
• налаштування валідації DNSSEC та режими відмов при помилках
• поведінку EDNS0 і обробку розміру відповіді

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

6) Хибне уявлення «це всього один стрибок»

Кожен додатковий стрибок здається малою рішенням: псевдонім до SaaS-ендпойнту, псевдонім до CDN, псевдонім до маркетингової платформи, псевдонім до
менеджера трафіку. Окремо — раціонально. Разом — ланцюг.

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

Одна цитата, яку варто тримати на стікері: «Сподівання — не стратегія.» — генерал Гордон Р. Салліван.

Факти та історичний контекст, що пояснюють сучасний безлад

DNS не новий, але спосіб його використання нині — дуже новий. Ланцюги CNAME поширені, бо ми продовжуємо накладати системи на протокол,
спроєктований для меншого, спокійнішого інтернету.

1. CNAME існує з ранніх RFC DNS, створений, щоб уникнути дублювання адресних записів для багатьох псевдонімів.
   Це інструмент для непрямої адресації, і непряма адресація завжди використовується.
2. DNS був спроєктований з припущенням, що кешування зробить основну роботу. Вся архітектура очікувала, що повторні запити будуть дешевими,
   бо рекурсивні резолвери кешують відповіді.
3. Негативне кешування стандартизували пізніше (кешування NXDOMAIN і подібних результатів), що зменшило навантаження, але внесло
   власну затримку при виправленні помилок введення.
4. EDNS0 ввели, щоб вирішити обмеження розміру відповіді. Це важливо, бо ланцюги CNAME разом із DNSSEC можуть роздути відповіді,
   що викликає фрагментацію або відкат на TCP.
5. CDN популяризували DNS-орієнтоване керування трафіком у величезному масштабі. Це часто означає короткі TTL і більш динамічні відповіді.
   Добре для маршрутизації; жорстко для кешів.
6. Багато підприємств почали ставитися до DNS як до менеджменту конфігурацій: «просто CNAME на ту річ». Це зручно і
   небезпечно легко робиться без вимірювання витрат.
7. Деякі резолвери вводять практичні обмеження на слідування за псевдонімами, щоб запобігти петлям і зловживанню ресурсами. Якщо ваш ланцюг довгий або дивний,
   деякі клієнти впадуть швидше за інших.
8. Впровадження DNSSEC принесло новий клас відмов: відповіді можуть бути «присутні, але недійсні», і помилки валідації можуть виглядати як таймаути залежно від поведінки клієнта.
9. «CNAME flattening» з’явився як обхідний шлях для кореневих записів, де CNAME заборонено. Це покращує деякі речі і ламає інші (далі більше).

Режими відмов, які ви справді побачите в продакшені

Глибина ланцюга та обмеження резолвера

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

Перервні NXDOMAIN від upstream

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

Фрагментація UDP і відкат на DNS по TCP

Великі DNS-відповіді можуть фрагментуватися. Фрагментований UDP недостовірно доставляється по всіх мережах. Коли фрагментація не спрацьовує, резолвери
пробують знову, переходять на TCP або таймаутять. Ланцюги CNAME збільшують розмір відповіді, а DNSSEC може зробити це ще гірше додаванням підписів.

Дивна поведінка двостековості (AAAA vs A)

Якщо ваш ланцюг закінчується A і AAAA, клієнти можуть віддати перевагу IPv6, а потім відкотитися на IPv4 (або навпаки). Якщо IPv6-зв’язок ненадійний,
відмова виглядає як «DNS повільний», бо резолюція пройшла, але встановлення з’єднання застрягло.

Сюрпризи split-horizon

Внутрішньо service.example.com може резолвитися в внутрішній VIP. Ззовні він може CNAME до вендора. Якщо ваш ланцюг змішує внутрішній і зовнішній вигляди,
хтось зрештою запустить неправильний резолвер у невідповідному місці і здивується, чому стейджинг викликає продакшн.

Петлі CNAME

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

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

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

Перш за все: перевірте, чи взагалі у вас є ланцюг і якої він глибини

• Запитайте за допомогою dig і перевірте розділ ANSWER на наявність кількох CNAME.
• Зверніть увагу на TTL на кожному стрибку.
• Визначте, чи ланцюг стабільний (однакові результати) або динамічний (відповіді швидко змінюються).

По-друге: відокремте затримку резолвера від затримки авторитарних серверів

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

По-третє: протестуйте поведінку при холодному та теплому кеші

• Запустіть повторні запити і подивіться, чи падає затримка після першого хіта.
• Якщо ні — TTL можуть бути занадто маленькі, відповіді занадто динамічні або кешування відключено/обхідне.

По-четверте: перевірте відкат на TCP / усічені відповіді

• Шукайте ознаки «TC» (усічення), великі відповіді або наклад DNSSEC.
• Тестуйте з +tcp, щоб побачити, чи робить TCP відповіді надійнішими (але повільнішими).

По-п’яте: скорелюйте з симптомами додатка

• Підтвердіть, чи додаток блокується на DNS (часто у синхронних HTTP-клієнтів при встановленні з’єднання).
• Перевірте перемішування пулів з’єднань під час деплойів/автоскейлінгу.
• Шукайте сплески у «нових з’єднаннях» та запитах DNS за секунду.

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

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

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

Завдання 1: Показати всю відповідь і помітити ланцюг

cr0x@server:~$ dig api.example.com A +noall +answer
api.example.com.        300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.      60 IN A     203.0.113.10

Що це означає: Два CNAME-стрибки перед A-записом. TTL 300 → 60 → 60, отже ви часто оновлюватимете hops вендора.
Рішення: Якщо це критичний ендпойнт (логін, оформлення замовлення, API), прагніть зменшити до ≤1 стрибка або домовтеся про довші TTL з вендором.

Завдання 2: Виміряти час запиту з вашого звичайного резолвера

cr0x@server:~$ dig api.example.com A +stats | tail -n 3
;; Query time: 84 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Wed Dec 31 12:03:11 UTC 2025

Що це означає: 84 мс для одного запиту з вашого середовища. Це не безкоштовно.
Рішення: Якщо бачите >20 мс всередині дата-центру — ставте під сумнів і продовжуйте із ізоляцією авторитарних серверів.

Завдання 3: Порівняти з публічним резолвером (перевірка здорового глузду, не фікс)

cr0x@server:~$ dig @1.1.1.1 api.example.com A +stats | tail -n 3
;; Query time: 19 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Wed Dec 31 12:03:26 UTC 2025

Що це означає: Публічний резолвер швидший. Ваш внутрішній резолвер може бути перевантажений, неправильно налаштований або далеко.
Рішення: Дослідіть стан і топологію внутрішнього резолвера; не просто «переключіться на публічний DNS» і вважайте це інженерним рішенням.

Завдання 4: Примусити «холодний» вигляд, обходячи кеш (наскільки це можливо)

cr0x@server:~$ dig api.example.com A +nocache +stats | tail -n 3
;; Query time: 92 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Wed Dec 31 12:03:45 UTC 2025

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

Завдання 5: Знайти авторитарні NS для вашої зони

cr0x@server:~$ dig example.com NS +noall +answer
example.com.          172800 IN NS ns1.dns-provider.net.
example.com.          172800 IN NS ns2.dns-provider.net.

Що це означає: Ваша зона обслуговується ns1/ns2.
Рішення: Опитайте їх безпосередньо, щоб побачити, чи ваші записи коректні і послідовні.

Завдання 6: Запитати ваш авторитарний сервер безпосередньо (перевірити перший стрибок)

cr0x@server:~$ dig @ns1.dns-provider.net api.example.com CNAME +noall +answer +stats
api.example.com.        300 IN CNAME api.edge.vendor.net.
;; Query time: 12 msec
;; SERVER: ns1.dns-provider.net#53(ns1.dns-provider.net) (UDP)

Що це означає: Ваш авторитарний швидко відповідає і повертає очікуваний CNAME.
Рішення: Ймовірно, ваша зона не проблема; переслідуйте наступний хоп вендора далі.

Завдання 7: Знайти авторитарні сервери зони вендора

cr0x@server:~$ dig edge.vendor.net NS +noall +answer
edge.vendor.net.      3600 IN NS ns-101.vendor-dns.net.
edge.vendor.net.      3600 IN NS ns-102.vendor-dns.net.

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

Завдання 8: Запитати авторитарний сервер вендора безпосередньо (виміряти другий стрибок)

cr0x@server:~$ dig @ns-101.vendor-dns.net api.edge.vendor.net CNAME +noall +answer +stats
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
;; Query time: 97 msec
;; SERVER: ns-101.vendor-dns.net#53(ns-101.vendor-dns.net) (UDP)

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

Завдання 9: Перевірити на невідповідності між авторитарними серверами вендора

cr0x@server:~$ for ns in ns-101.vendor-dns.net ns-102.vendor-dns.net; do dig @$ns api.edge.vendor.net CNAME +noall +answer; done
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.edge.vendor.net.     60 IN CNAME api-alt.geo.vendor.net.

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

Завдання 10: Виявити петлі CNAME або надмірне переслідування за допомогою trace

cr0x@server:~$ dig api.example.com A +trace
; <<>> DiG 9.18.24 <<>> api.example.com A +trace
;; Received 525 bytes from 10.0.0.53#53(10.0.0.53) in 1 ms
example.com.     172800 IN NS ns1.dns-provider.net.
example.com.     172800 IN NS ns2.dns-provider.net.
api.example.com.    300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net. 60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.  60 IN A 203.0.113.10

Що це означає: Trace чітко показує ланцюг. Якщо ви бачили повторні стрибки між двома іменами — це петля.
Рішення: Якщо з’явилася петля або дуже довгий ланцюг — виправте негайно; не «чекайте і дивіться».

Завдання 11: Перевірити усічення та ризик відкату на TCP

cr0x@server:~$ dig api.example.com A +dnssec +bufsize=1232 +noall +comments +answer
;; Got answer:
;; WARNING: Message has 1 extra bytes at end
api.example.com.        300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.      60 IN A     203.0.113.10

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

Завдання 12: Примусити TCP, щоб побачити, чи «UDP ненадійний»

cr0x@server:~$ dig api.example.com A +tcp +stats | tail -n 3
;; Query time: 143 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (TCP)
;; WHEN: Wed Dec 31 12:05:02 UTC 2025

Що це означає: TCP повільніший, але може бути надійнішим у деяких мережах. Якщо по UDP — таймаути, а по TCP працює, у вас проблема шляху/MTU/фрагментації.
Рішення: Виправте проблеми мережевого шляху і розміру відповіді. Не насильно переводьте все на TCP як «рішення», якщо вам не подобається платити латентні податки назавжди.

Завдання 13: Проінспектувати конфігурацію локального резолвера (подивитись, чим ви реально користуєтесь)

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 Domain: corp.example

Що це означає: Ви використовуєте внутрішні резолвери; валідація DNSSEC на цьому шарі вимкнена (вона може бути увімкнена upstream).
Рішення: Якщо латентність сильно відрізняється між 10.0.0.53 і 10.0.0.54 — розподілення навантаження або перевірки здоров’я зроблені неправильно. Виправте здоров’я флоту резолверів перед зміною записів.

Завдання 14: Виміряти поведінку резолвера з часом (розподіл латентності, а не один зразок)

cr0x@server:~$ for i in {1..10}; do dig api.example.com A +stats +noall +answer; done
api.example.com.        300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.      60 IN A     203.0.113.10
api.example.com.        300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.      60 IN A     203.0.113.10

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

Завдання 15: Перевірити, чи хост додатка не «бомбить» DNS (системний погляд)

cr0x@server:~$ sudo ss -uapn | grep ':53 ' | head
UNCONN 0 0 10.10.5.21:58642 10.0.0.53:53 users:(("python3",pid=24817,fd=9))
UNCONN 0 0 10.10.5.21:49811 10.0.0.53:53 users:(("java",pid=11302,fd=123))

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

Завдання 16: Перевірити, чи ланцюг завершується як A і AAAA (або навмисно ні)

cr0x@server:~$ dig api.example.com A AAAA +noall +answer
api.example.com.        300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.      60 IN A     203.0.113.10
api.geo.vendor.net.      60 IN AAAA  2001:db8::10

Що це означає: Увімкнено двостек. Добре — якщо ваша мережа надійно підтримує IPv6.
Рішення: Якщо клієнти в деяких середовищах падають через IPv6, ви побачите «випадкові» затримки. Розгляньте стан IPv6, поведінку Happy Eyeballs або навмисне відключення AAAA, якщо ви не можете його підтримати.

Три корпоративні міні-історії (анонімізовано, боляче правдоподібно)

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

Команда продукту перемістила свій публічний API-ендпойнт за шлюз безпеки. План міграції був «безпечний», бо вони не міняли IP — вони лише оновили DNS.
Початковий api.example.com став CNAME до імені шлюзу.

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

Ланцюг виявився трьома CNAME-глибинами, бо вендор шлюзу використовував регіональний псевдонім, який потім вказував на псевдонім per-POP, який нарешті повертав A/AAAA.
TTL вендора були 30–60 секунд. За стабільного навантаження це було прийнятно. Під час хвилі деплойів флот почав агресивно резолвити. QPS резолвера підскочив, потім зросла латентність резолюції, потім зросла латентність запитів, і врешті таймаути клієнта перетворилися на повторні спроби. Класична позитивна петля.

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

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

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

Маркетинг хотів «миттєвий» фейловер між двома CDN, плюс WAF, плюс сервіс оптимізації зображень. Хтось запропонував елегантну DNS-непряму: CNAME усе до всього, тримати низькі TTL і нехай вендори маршрутизують динамічно.
Звучало модно. Насправді це стало сендвічем залежностей.

Побудували: assets.example.com CNAME до менеджера трафіку, який CNAME до WAF, який CNAME до обраного CDN, що CNAME до регіонального edge-імені.
На папері — просто псевдоніми. На практиці — ланцюг через кількох провайдерів з різними характеристиками відмов і різним розумінням «TTL 60 секунд».

Провал стався під час інциденту провайдера, що навіть не був повним простоєм: авторитарні сервери одного вендора були доступні, але повільні.
Рекурсивні резолвери почали таймаутити і повторно спробувати. Деякі повертали SERVFAIL, деякі — застарілі кешовані дані, деякі переходили на TCP. Досвід користувачів різнився за регіонами та ISP.

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

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

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

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

Одного дня моніторинг подав тривогу, що час резолюції login.example.com піднявся вище порога в двох регіонах.
Не затримка додатка. Не TLS handshake. Саме резолюція DNS. Алерт включав спостережуваний ланцюг і який хоп повільний.

Вони подивилися інвентар: login.example.com дозволено один CNAME до їхнього менеджера трафіку, і далі він має завершуватися A/AAAA записами під їхнім контролем.
Це означало, що є лише їхні авторитарні сервери. Жодної сторонньої залежності в ланцюгу. Повільний хоп був всередині краю їхнього DNS-провайдера для тих регіонів.

Вони виконали нудну контингентну дію: переключили NS-делегацію на вторинного провайдера (попередньо налаштованого, протестованого щокварталу), чекали пропагацію і спостерігали падіння часу резолюції.
Користувачі майже не помітили. Інцидент не став повним простоєм.

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

Жарт №2: DNS — єдине місце, де додавання «ще одного псевдоніма» може перетворитися на детектив з кількома авторами і без редактора.

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

1) Симптом: випадкові сплески латентності API, що не відповідають метрикам бекенду

Корінна причина: Резолюція DNS на шляху запиту через часті нові з’єднання; ланцюг CNAME з коротким TTL збільшує промахи кеша.

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

2) Симптом: деякі клієнти падають, інші працюють — за географією або ISP

Корінна причина: Авторитарні сервери вендора непослідовні або повільні у деяких регіонах; рекурсивні резолвери поводяться по-різному; EDNS0 поводиться неоднаково.

Виправлення: Опитайте авторитарні сервери вендора безпосередньо з постраждалих регіонів; домагайтеся послідовності; розгляньте завершення ланцюга у вашій зоні з A/AAAA до anycast-ендпойнтів вендора, якщо вони це пропонують.

3) Симптом: після зміни DNS з’являється SERVFAIL, потім «саме по собі» виправляється

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

Виправлення: Перевірте ланцюжок довіри DNSSEC; перевірте DS-записи та авторитарні відповіді; швидко ролбекніть; тримайте TTL розумними під час міграцій.

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

Корінна причина: Різні резолвери (VPN/корпоративний vs кластерний DNS), різні egress-шляхи або відмінності в кешуванні на вузлі; ланцюг досягає обмежень резолвера під навантаженням.

Виправлення: Тестуйте з того самого середовища, що й невдалий ворклоад; налаштуйте CoreDNS/локальний резолвер вузла; зменште глибину ланцюга; уникайте ультранизьких TTL, що нівелюють кешування.

5) Симптом: «тимчасова помилка в резольвінні імені» під час деплоїв/автоскейлінгу

Корінна причина: Перевантаження резолвера через вибухові холодні старти; ланцюг CNAME множить upstream-запити; короткий TTL змушує часті оновлення.

Виправлення: Масштабуйте флот резолверів; додайте рівні кешування; розбивайте релізи; передпрогрівайте критичні DNS-кеші; мінімізуйте CNAME-хопи для гарячих хостів.

6) Симптом: DNS-запити раптово переходять на TCP і латентність зростає

Корінна причина: Великі відповіді (ланцюг CNAME + DNSSEC), усічення або проблеми шляху MTU/фрагментації.

Виправлення: Зменшіть розмір відповіді (скоротіть ланцюг, видаліть непотрібні записи), переконайтеся, що резолвери підтримують EDNS0 правильно, і перевірте MTU/обробку фрагментації в мережі.

7) Симптом: переривчастий NXDOMAIN для імені, яке існує

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

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

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

Чекліст A: Визначити, чи підходить CNAME

1. Чи ім’я критичне? (логін, оформлення замовлення, API, прийом вебхуків). Якщо так — агресивно обмежуйте глибину ланцюга.
2. Чи контролюєте ви наступний хоп? Якщо ні — ви імпортуєте чужий uptime у свій.
3. Чи TTL < 60 с? Якщо так — передбачайте велике навантаження резолверів і вищу латентність у хвості під час пертурбацій.
4. Чи потрібна поведінка apex? Якщо так — будьте обережні з flattening; розберіться, що робить ваш провайдер «за лаштунками».
5. Чи можете ви безпечно використовувати A/AAAA? Якщо IP-адреси стабільні або anycast, віддавайте перевагу прямим записам для критичних ендпойнтів.

Чекліст B: Безпечно зменшити глибину ланцюга (план міграції)

1. Інвентаризуйте поточний ланцюг за допомогою dig; зафіксуйте hops і TTL.
2. Підтвердіть, чи вендор пропонує стабільний ендпойнт для прямого A/AAAA (деякі пропонують).
3. Зменште TTL на поточному записі перед cutover (за години/дні до, залежно від існуючого TTL).
4. Впровадьте новий таргет паралельно (якщо можливо) і протестуйте з кількох мереж.
5. Переключайте у вікно низького ризику; моніторте латентність резолюції і рівні помилок.
6. Після стабільності підніміть TTL до здорового значення (часто хвилини — години, залежно від вашого циклу змін).
7. Задокументуйте відповідальність: хто затверджує майбутні DNS-непрямі для цього імені.

Чекліст C: Моніторити ланцюг як залежність SLO

1. Відстежуйте латентність резолюції DNS (p50/p95/p99) з репрезентативних мереж клієнтів.
2. Алертуйте при зміні глибини ланцюга (тиха зміна вендора може додати hops).
3. Алертуйте при авторитарній непослідовності (різні відповіді між NS).
4. Відстежуйте ставки SERVFAIL/NXDOMAIN окремо від помилок додатка.
5. Під час інцидентів захоплюйте: використаний резолвер, час запиту, ланцюг відповіді і чи був потрібен TCP.

Чекліст D: Якщо ланцюг мають залишити (через бізнес)

1. Тримайте його коротким: один стрибок — пріоритет, два — узгоджений виняток, три — запах архітектурної проблеми.
2. Вимагайте від вендора SLO для їхнього авторитарного DNS і публічні шляхи ескалації.
3. Попросіть регіональні anycast-ендпойнти або «прямі» імена для клієнтів з великим QPS.
4. Зробіть політику TTL явною: надто низькі TTL — це функція продуктивності, яка потребує навантажувального тестування.
5. Майте план відкату під вашим контролем (резервне ім’я, альтернативний провайдер або кешований ендпойнт) і практикуйте його.

ЧАСТІ ПИТАННЯ

1) Скільки CNAME — це «занадто»?

Для критичних шляхів: більше одного вже ризик. Більше двох має бути рідкістю і обґрунтованим вимірюваннями та моніторингом.
Для некритичних імен (маркетингові сторінки, ванітні хости) можна терпіти більше — але все одно слід стежити.

2) Чи завжди ланцюги CNAME додають затримку?

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

3) Чому короткий TTL робить ситуацію гіршою, якщо він «більше динамічний»?

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

4) Чи варто просто запускати власні рекурсивні резолвери скрізь?

Іноді. Локальні резолвери на вузлі або у VPC можуть зменшити латентність і захистити від частини upstream-поломок. Але це також робить вас оператором
ще однієї розподіленої системи. Якщо ви не вмієте її моніторити і масштабувати — ви створите новий режим відмов.

5) А як щодо CNAME flattening?

Flattening — це фіча провайдера, яка повертає A/AAAA на apex, коли ви конфігуруєте псевдонім як CNAME. Це може зменшити видиму клієнту глибину ланцюга,
але переносить складність на провайдера і може змінити поведінку TTL. Ставтесь до цього як до продуктної фічі з компромісами, а не як до безкоштовного обіду.

6) Чи можуть ланцюги CNAME ламати TLS або сертифікати?

Безпосередньо — ні. TLS перевіряє ім’я хоста, до якого підключається клієнт, а не ціль CNAME. Але ланцюги можуть спрямовувати клієнтів до різних кінцевих точок несподівано,
і якщо конфігурація вендора непослідовна, ви можете отримати невідповідність сертифікатів на досягнутому IP.

7) Чому ми бачимо NXDOMAIN для запису, який існує?

Тому що DNS розподілений і кешує також негативні результати. Якщо авторитарний сервер тимчасово відповідає NXDOMAIN (проблеми пропагації, split-brain),
резолвери можуть закешувати це на деякий час. Це «деякий час» визначається SOA-настройками і політикою резолвера, а не вашим терпінням.

8) Як довести вендору, що їхній DNS повільний?

Опитайте їхні авторитарні сервери безпосередньо (по імені), зафіксуйте часи запитів з постраждалих регіонів і покажіть непослідовності між їхніми NS.
Надайте тимчасові мітки, ім’я, яке запитували, і чи змінився результат при UDP vs TCP.

9) Чи впливають ланцюги CNAME на кешування CDN і браузерів?

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

10) Чи завжди краще замінити CNAME на A/AAAA?

Це краще для продуктивності і надійності, коли IP-адреси стабільні і ви можете безпечно оперувати змінами. Це гірше, коли вендор змінює IP без повідомлення
або коли ви втрачаєте логіку маршрутизації, яка вам потрібна. Якщо ви використовуєте A/AAAA — ви приймаєте на себе більше відповідальності.

Наступні кроки (ті, що зменшують шум зі пейджера)

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

Практичні кроки, які ви можете зробити цього тижня:

1. Інвентаризуйте критичні імена і зафіксуйте їхню глибину ланцюга та TTL.
2. Виміряйте латентність резолюції DNS (p50/p95/p99) з тих же мереж, що й ваші користувачі та ворклоади.
3. Встановіть бюджет: один CNAME-стрибок для критичних імен, якщо немає письмового винятку.
4. Спрощуйте найгірші випадки першочергово: скорочуйте ланцюги, віддавайте перевагу стабільним ендпойнтам або завершуйте непряму в зонах під вашим контролем.
5. Моніторте дрейф ланцюга: вендори змінюють поведінку DNS без повідомлення, бо так вони роблять.
6. Репетируйте контингентний план для DNS для одного критичного імені. Першу практику проводьте не під час інциденту.

Якщо винести лише один урок: коли ваша система залежить від DNS у масштабі, ставтеся до DNS як до продакшен-інфраструктури, а не як до форми, яку заповнюють раз на рік.