Помилки TTL DNS, що переслідують міграції — як налаштувати TTL як профі

TTL — це не «пропагація»: що насправді відбувається

TTL (time to live) — це кількість секунд, скільки відповідь DNS має право жити в кеші. Не те, скільки часу потрібно «інтернету», щоб дізнатися про вашу зміну. Фраза «DNS propagation» — це маркетинг для тих, хто продає домени та знеболювальне.

Ось реальний потік у продакшені:

• Авторитетний DNS зберігає істину для зони (ваші записи, ваш SOA, набір NS).
• Рекурсивні резольвери (резольвери провайдерів, корпоративні резольвери, публічні) витягують і кешують відповіді від авторитетних серверів.
• Stub-резольвери на машинах питають рекурсивний резольвер. Вони теж можуть кешувати, залежно від ОС, бібліотек і локальних демонів.
• Кешування на рівні застосунків також трапляється. Java, Go, Envoy, браузери, CDN edge і загадкові SDK іноді кешують DNS так, як ви не просили.

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

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

Жарт №1: DNS «пропагація» — це як «ми повернемося до цього» в корпоративній пошті: означає «не за вашим графіком».

Цікаві факти та коротка історія (корисно на нарадах)

1. DNS замінив HOSTS.TXT, бо централізований файл не масштабується. TTL існує тому, що кешування — єдиний спосіб, як глобальна система імен виживає.
2. TTL був у DNS з ранніх RFC як основний механізм контролю кешування. Це не опційний регулятор; це контракт.
3. Негативне кешування стандартизували пізніше, коли оператори зрозуміли, що постійні запити «чи існує це ім’я?» руйнують резольвери під час відмов і атак.
4. SOA має дві різні концепції «мінімуму» історично: старі семантики проти сучасного використання для негативного TTL. Плутанина тут досі викликає проблеми під час міграцій.
5. Резольвери можуть обрізати TTL (і мінімум, і максимум) через політику або продуктивність. Ваш 30-секундний TTL може стати 300 секундами в деяких мережах.
6. Деякі платформи фактично ігнорують TTL, бо фіксують відповіді або агресивно кешують. Це не поломка DNS — це поведінка застосунку.
7. CDN і глобальні балансувальники навантаження часто покладаються на DNS саме тому, що TTL дає контрольований «керований перехід» трафіку. Якщо використовувати правильно, це надійно й передбачувано.
8. Низькі TTL раніше не радили, коли авторитетні сервери були слабші й трафік дорожчий. Сьогодні це більше про дисципліну в операціях, ніж про витрати.
9. EDNS і сучасні можливості резольверів покращили продуктивність і стійкість, але не ліквідовували кешування. Кешування — усе ще суть.

Ментальна модель TTL, яка витримає реальні мережі

Якщо запам’ятати лише одну модель, використайте цю:

Спостережуваний час cutover = max(шари кешування) + ваші власні помилки.

Шар 1: кешування рекурсивного резольвера

Це головне. Ваші користувачі не опитують ваші авторитетні сервери безпосередньо; вони питають резольвер. Цей резольвер зазвичай поважає TTL, але може його обрізати. Якщо резольвер кешував стару відповідь п’ять хвилин тому з TTL на 1 годину, ви можете робити зміни хоч щохвилини — ці користувачі прив’язані до старої відповіді до 55 хвилин.

Шар 2: кешування на рівні хоста і stub-резольвера

На Linux у вас може бути systemd-resolved, nscd, dnsmasq або нічого. На macOS є поведінка mDNSResponder. На Windows — служба DNS Client. Деякі з них дотримуються TTL, дехто має додаткову логіку, а деякі застосунки обходять їх.

Шар 3: кешування в застосунках і рантаймах

Браузери можуть кешувати DNS, але також і ваш HTTP-клієнт. JVM історично мав налаштування «кешувати вічно» в деяких режимах. Деякі service mesh або sidecar кешують агресивно для продуктивності. І деякі команди написали власну «DNS-кеш» бібліотеку, бо їх раз викликали через затримки резольвера. Вгадайте що: тепер вони викликають вас через міграції.

Шар 4: повторне використання з’єднань і тривалі сесії

Навіть якщо DNS оновився миттєво, трафік може не переміститися, бо клієнти тримають TCP-з’єднання живими. HTTP/2, gRPC, WebSockets, пул бази даних — вони всі призначені для стійкості. DNS впливає тільки на нові з’єднання (якщо ви явно не злили/закрили їх). Під час міграції тривалість з’єднань може важити більше за TTL.

Чому «встановити TTL 60 секунд» не означає автоматично «cutover за 60 секунд»

Бо запис може вже бути закешований з більшим TTL, існує негативне кешування, резольвери можуть обрізати TTL, є кеші застосунків і повторне використання з’єднань.

TTL — не секундомір. Це максимальний вік від моменту кешування. Якщо вам потрібна передбачуваність, плануйте у зворотному порядку: знижуйте TTL завчасно, щоб кеші оновилися до вказаного низького TTL перед вікном cutover.

Цитата, що стане в пригоді в розмовах про надійність:

«Сподівання — це не стратегія.» — перефразована ідея, яку приписують багатьом інженерам з надійності та лідерам SRE

Як налаштувати TTL як профі (перед, під час та після cutover)

Крок 0: вирішіть, що означає «cutover» у вашій системі

DNS cutover — лише один важіль. Перед тим як чіпати TTL, визначте:

• Чи ви переміщуєте усі потоки або лише підмножину?
• Чи потрібен вам швидкий відкат (хвилини) або допустимі години?
• Клієнти внутрішні (корпоративні резольвери, які ви контролюєте) чи зовнішні (хаотичний зоопарк)?
• Сервіси станові (бази даних) чи безстанні (веб/API)?
• Чи є у вас другий контрольний рівень (ваги балансувальника, конфіг CDN, service discovery), який може бути кращим за DNS?

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

Перед cutover: знижуйте TTL завчасно, а не «одразу перед»

Професійний крок — знизити TTL принаймні на повний попередній період TTL до cutover. Краще — на два. Бо світ міг кешувати запис у будь-який момент під час попереднього TTL-вікна.

Приклад: ваш поточний TTL — 3600 секунд (1 година). Ви хочете вікно cutover 60 секунд. Знизьте TTL до 60 принаймні за 1 годину до cutover — і бажано раніше. Це дасть кешам шанс оновитися й почати дотримуватися нового низького TTL.

Вибирайте розумні значення TTL (без хитрощів)

Ось опінійований старт, що працює для більшості міграцій:

• Звична робота (steady-state): 300–900 секунд для більшості A/AAAA; 900–3600 для записів, що рідко змінюються.
• Вікно міграції: 30–120 секунд для конкретних імен, які ви будете перемикати.
• Після cutover: підніміть назад до 300–900, коли все стабільно; не лишайте все на 30 секундах назавжди, якщо ви не прорахували навантаження на запити і аудит резольверів.

Так, 30-секундні TTL можливі. Ні, вони не безкоштовні. Ви платите за навантаження на резольвери, QPS авторитетних серверів і складність інцидентів, коли ваш DNS-провайдер матиме поганий день.

Cutover: змінюйте правильний запис у правильному місці

Більшість міграцій провалюється тому, що хтось змінив якийсь запис, а не той запис.

• Якщо у вас є ланцюг (CNAME → ще один CNAME → A/AAAA), ви повинні розуміти TTL на кожному кроці.
• Якщо у вас split-horizon DNS, змінюйте внутрішні та зовнішні перегляди навмисно.
• Якщо ви використовуєте керований DNS плюс внутрішню зону-override, знайте, яка відповідь переможе для яких клієнтів.

Також: якщо ви працюєте з апекс-записом (apex, example.com) і робите хитрі CNAME-подібні трюки, будьте дуже обережні. Поведінка провайдера може змінити те, які TTL фактично з’являються у відповідях.

План відкату: TTL — ваш регулятор радіусу ураження

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

Після cutover: піднімайте TTL і спостерігайте за відсталими клієнтами

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

І стежте за відсталими клієнтами. Вони завжди є: вбудовані пристрої, старі JVM, корпоративні проксі й «допоміжні» бібліотеки, що фіксують DNS.

Жарт №2: Встановити TTL 5 секунд — відчуття влади, поки не прийде рахунок за DNS, як за звіт про ефективність.

Практичні завдання: 12+ перевірок і рішень через команди

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

Завдання 1: Підтвердити, що світ бачить авторитетну відповідь (через +trace)

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

; <<>> DiG 9.18.24 <<>> +trace www.example.com A
;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms

www.example.com.      60      IN      A       203.0.113.42
;; Received 56 bytes from 198.51.100.53#53(ns1.example.net) in 22 ms

Значення: Кінцева відповідь показує TTL=60 на авторитетному джерелі (як спостерігається через trace). Це «істина», яка наразі видається.

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

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

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

www.example.com.      47      IN      A       203.0.113.42

Значення: Резольвер Cloudflare закешував запис і тримає його ще 47 секунд.

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

Завдання 3: Порівняйте кілька резольверів, щоб виявити обрізання або застарілі кеші

cr0x@server:~$ for r in 1.1.1.1 8.8.8.8 9.9.9.9; do dig @$r www.example.com A +noall +answer +ttlid; done

www.example.com.      52      IN      A       203.0.113.42
www.example.com.      300     IN      A       203.0.113.42
www.example.com.      58      IN      A       203.0.113.42

Значення: Один резольвер фактично використовує 300 секунд. Це може бути обрізання або він кешував раніше, ніж TTL було знижено.

Рішення: Якщо важливий досвід зовнішніх користувачів — плануйте за найгіршою спостережуваною поведінкою кешування. Ваш «60-секундний» cutover не обов’язково буде 60 секундами глобально.

Завдання 4: Проінспектуйте ланцюги CNAME і TTL на кожному кроці

cr0x@server:~$ dig www.example.com CNAME +noall +answer +ttlid

www.example.com.      60      IN      CNAME   app-lb.example.net.

cr0x@server:~$ dig app-lb.example.net A +noall +answer +ttlid

app-lb.example.net.   300     IN      A       198.51.100.77

Значення: Навіть якщо TTL для CNAME — 60, A-запис, на який він вказує, може мати TTL 300 і кешуватися незалежно.

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

Завдання 5: Підтвердіть поведінку AAAA (IPv6 може здивувати)

cr0x@server:~$ dig www.example.com AAAA +noall +answer +ttlid

www.example.com.      60      IN      AAAA    2001:db8:10::42

Значення: Клієнти, що віддають перевагу IPv6, підуть цим шляхом. Якщо ви оновили лише A, половина трафіку може ігнорувати зміни.

Рішення: Розглядайте A і AAAA як пару. Міґруйте обидва або навмисно вимкніть один (з повним усвідомленням наслідків).

Завдання 6: Перевірте негативне кешування (NXDOMAIN) перед створенням нових імен

cr0x@server:~$ dig newservice.example.com A +noall +answer +authority

example.com.          900     IN      SOA     ns1.example.net. hostmaster.example.com. 2025123101 3600 600 1209600 300

Значення: Немає секції answer; секція authority показує SOA з параметром для негативного кешування (зазвичай 300 тут).

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

Завдання 7: Переконайтеся в наборі авторитетних NS та коректності делегації

cr0x@server:~$ dig example.com NS +noall +answer

example.com.          3600    IN      NS      ns1.example.net.
example.com.          3600    IN      NS      ns2.example.net.

Значення: Це ті авторитетні сервери, до яких клієнти мають звертатися (після делегації).

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

Завдання 8: Перевірте SOA serial і чи другі сервери підхопили зміни

cr0x@server:~$ dig @ns1.example.net example.com SOA +noall +answer
example.com.          900     IN      SOA     ns1.example.net. hostmaster.example.com. 2025123102 3600 600 1209600 300

cr0x@server:~$ dig @ns2.example.net example.com SOA +noall +answer
example.com.          900     IN      SOA     ns1.example.net. hostmaster.example.com. 2025123101 3600 600 1209600 300

Значення: ns2 відстає (серіал відрізняється). Ваша «зміна» ще не обслуговується глобально.

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

Завдання 9: Спостерігайте TTL з конкретного клієнтського хоста (шлях системного резольвера)

cr0x@server:~$ resolvectl query www.example.com

www.example.com: 203.0.113.42                    -- link: eth0
                 (A) --> 47s

Значення: systemd-resolved показує залишковий TTL у своєму кеші для цього хоста.

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

Завдання 10: Визначте, яким резольвером користується хост (ви будете здивовані)

cr0x@server:~$ cat /etc/resolv.conf
nameserver 10.0.0.53
search corp.example
options timeout:1 attempts:2

Значення: Цей хост використовує корпоративний резольвер, а не публічний DNS. Ваші зовнішні тести можуть бути неактуальними.

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

Завдання 11: Підтвердьте статус кешу резольвера (приклад для BIND)

cr0x@server:~$ sudo rndc dumpdb -cache
cr0x@server:~$ sudo grep -n "www.example.com" /var/cache/bind/named_dump.db | head
12451:www.example.com. 47 IN A 203.0.113.42

Значення: Локальний рекурсивний резольвер має запис у кеші зі 47 секундами залишку.

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

Завдання 12: Виміряйте, чи користувачі застрягли на старих IP через логи

cr0x@server:~$ sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
  912 203.0.113.10
  301 198.51.100.77
  118 203.0.113.11

Значення: Запити надходять на кілька фронтендів/IP. Якщо 198.51.100.77 — «старий» endpoint, деякі клієнти ще не перейшли.

Рішення: Тримайте старий endpoint здоровим, поки хвіст не зникне, або активно зливайте/редиректьте. Не вимикайте його «бо DNS».

Завдання 13: Перевірте, що новий endpoint відповідає правильно (не довіряйте лише DNS)

cr0x@server:~$ curl -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" --resolve www.example.com:443:203.0.113.42 https://www.example.com/healthz
200 203.0.113.42

Значення: Ви примусово підключилися до нового IP, зберігши hostname для TLS/SNI. Хелсчек пройшов.

Рішення: Якщо це не вдається — не робіть DNS-зміну. Виправте новий endpoint спочатку. DNS — не інструмент тестування; це руль.

Завдання 14: Перевірте довгоживучі з’єднання, які ігнорують зміни DNS

cr0x@server:~$ ss -antp | grep ':443' | head
ESTAB 0 0 203.0.113.42:443 198.51.100.25:52144 users:(("nginx",pid=2210,fd=44))
ESTAB 0 0 203.0.113.42:443 198.51.100.25:52145 users:(("nginx",pid=2210,fd=45))

Значення: Існують активні сесії. Якщо ви зміните DNS, існуючі клієнти можуть продовжувати спілкування зі старим endpoint, доки ці з’єднання не закриються.

Рішення: Плануйте дренаж і контроль часу життя з’єднань (keepalive, graceful shutdown) разом зі змінами TTL.

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

cr0x@server:~$ dig www.example.com A +dnssec +noall +answer +adflag

www.example.com.      60      IN      A       203.0.113.42

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

Рішення: Під час міграцій провайдерів керуйте DS-записами і підписуванням обережно. Збої DNSSEC виглядають як випадкові відмови з коментарями «але в мене DNS виглядає нормально».

План швидкої діагностики (перший/другий/третій)

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

Перший: чи авторитетна істина правильна?

• Запустіть dig +trace для точного імені і типу (A, AAAA, CNAME).
• Перевірте TTL, цілі та чи відповідь збігається з бажаним призначенням.
• Перевірте SOA serial на всіх авторитетних серверах, якщо їх декілька.

Якщо авторитетна відповідь неправильна — зупиняйтеся. Виправте зону. Все інше — шум.

Другий: чи резольвери повертають застарілі відповіді?

• Опитайте резольвери, якими користуються ваші клієнти (корпоративні, публічні, регіональні).
• Порівняйте залишковий TTL і повернуті IP.
• Шукайте обрізання TTL (неочікувано високий TTL) або розділену поведінку (деякі резольвери старі, деякі — нові).

Якщо резольвери застарілі, ви чекаєте на кеші, якщо тільки не контролюєте резольвери і не можете вибірково їх очистити.

Третій: чи трафік застряг через причини, не пов’язані з DNS?

• Перевірте, чи клієнти тримають старі з’єднання до старих endpoint.
• Перевірте кешування DNS на клієнтському боці в рантаймах (JVM, sidecar, проксі).
• Перевірте LB/health checks: можливо DNS змінився, але новий бекенд нездоровий і логіка маршрутизації веде назад.

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

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

1) Інцидент через неправильне припущення

Вони мігрували портал клієнта з колокації на хмарний балансувальник. План казав: «Знизити TTL до 60 секунд напередодні, потім перемкнути A-запис опівночі». Чисто і цивілізовано.

Інженер з чергування знизив TTL — але не того запису. Було гарне ланцюгування CNAME: portal.example.com CNAME-ився в portal.edge.example.net, а той мав A-запис, що вказував на старий VIP. Вони знизили TTL для portal.example.com, але лишили portal.edge.example.net на 3600.

Опівночі вони перевернули A-запис в цільовому імені, але кеші по світу все ще тримали старий A до години. Деякі клієнти потрапляли на новий портал, деякі — на старий, сесії стрибали залежно від того, який резольвер вам попався. Підтримка бачила «випадкові логаути». Інженери — «неможливо відтворити». Всі одночасно помилялися.

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

2) Оптимізація, що відсепалась

Інша компанія мала високонавантажений API і вирішила, що DNS-латентність занадто дорога. Вони додали in-process DNS-кеш у бібліотеку клієнта з мінімальним TTL 10 хвилин. Мета: зменшити QPS до резольвера і трохи зменшити p99.

Працювало. Графи резольверів впали. Латентність трохи покращилась. Всі про це забули, бо дашборди зелені й ніхто не любить читати RFC під час хорошого кварталу.

Потім сталася регіональна міграція. Вони планували поступове перемикання через зважений setup під CNAME. На папері 60-секундний TTL давав швидкий контроль. На практиці великі клієнти з тією бібліотекою тримали старі відповіді по 10 хвилин, і зміна йшла як вперта сходинка.

Гірше: відкат не був реальним. Коли частина запитів почала падати в новому регіоні, вони «відкатили» DNS, але кеш продовжував кидати трафік у проблемний регіон ще хвилини. Інженери почали сумніватися в інструментах. Бізнес — в інженерії. Так ви втрачаєте довіру, не тільки аптайм.

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

3) Нудна, але правильна практика, що врятувала вечір

Одна команда мала ритуал. Перед будь-якою великою міграцією вони 48 годин до справи проводили «DNS readiness drill». Не нараду — тренування. Вони перевіряли поточні TTL, знижували їх у контрольованій зміні і валідували з кількох точок (корпоративні резольвери, публічні резольвери і кілька регіонів у хмарі).

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

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

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

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

1) «Ми змінили DNS, але деякі користувачі ще годинами потрапляють на старий сайт»

Симптом: Змішаний трафік на старі й нові endpoint довго після cutover.

Корінь проблеми: Старий TTL був великий і ви знизили занадто пізно; або резольвери кешували до зміни TTL; або резольвер обрізав TTL вгору.

Виправлення: Знижуйте TTL принаймні на повний попередній період TTL до cutover (краще два). Перевіряйте TTL на кількох резольверах. Плануйте тримати старий endpoint живим для хвоста.

2) «Внутрішні користувачі бачать нове, зовнішні — старе»

Симптом: Співробітники звітують про успіхи; клієнти — про відмови (або навпаки).

Корінь проблеми: Split-horizon DNS, внутрішні override-зони або різні резольвери з різними станами кешу.

Виправлення: Документуйте, які резольвери і зони обслуговують які клієнти. Тестуйте cutover зсередини і зовні. Оновіть обидва перегляди навмисно.

3) «Ім’я каже NXDOMAIN, потім пізніше працює»

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

Корінь проблеми: Негативне кешування NXDOMAIN через негативний TTL у SOA; або ім’я було запитане до створення і кешовано як «не існує».

Виправлення: Створюйте імена заздалегідь; тримайте негативний TTL в розумних межах; перевіряйте параметри SOA; уникайте введення нових імен під час cutover.

4) «Ми зменшили TTL, але клієнти й досі його не поважають»

Симптом: Деякі клієнти прив’язані до IP далеко за межами TTL.

Корінь проблеми: Кешування в рантаймі/застосунках (налаштування JVM, кастомні кеші, sidecar), або довгоживучі з’єднання.

Виправлення: Проведіть аудит поведінки DNS у клієнтів. Налаштуйте кеші так, щоб вони поважали TTL. Встановіть макс-віки з’єднань, реалізуйте дренаж і плануйте стікінесс сесій окремо від DNS.

5) «Ми перевернули A-запис, але нічого не змінилося»

Симптом: Моніторинг і користувачі все ще йдуть на старий endpoint.

Корінь проблеми: Ви змінили не те ім’я/тип (ланцюг CNAME, інший запис у використанні), або існує внутрішнє override.

Виправлення: Замапте шлях резолюції (dig CNAME + trace). Підтвердьте, яке ім’я і тип запитують клієнти. Видаліть або оновіть override.

6) «Після міграції провайдера DNS деякі користувачі не можуть розв’язати зовсім»

Симптом: SERVFAIL або таймаути для частини резольверів.

Корінь проблеми: Несумісність делегації, відсутні записи, неповна зона або несумісність DNSSEC DS/підписів.

Виправлення: Перевірте делегацію NS, повноту авторитетної зони і ланцюг DNSSEC перед NS cut. За можливості зберігайте старого провайдера у режимі overlap.

7) «Відкат не відкотив»

Симптом: Ви повернули DNS, але трафік продовжує йти на нову поламану ціль.

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

Виправлення: Розглядайте відкат як планований перелаштування з власним вікном кешування. Тримайте низький TTL до cutover і керуйте дренажем/таймаутами з’єднань.

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

Плануйте у зворотному порядку від вікна cutover

1. Інвентаризуйте імена, що беруть участь (клієнтські, внутрішні, API, callback, webhook, SAN у сертифікатах).
2. Замапте резолюцію: A/AAAA проти ланцюга CNAME, split-horizon перегляди, внутрішні overrides.
3. Зафіксуйте поточні TTL для кожного запису в ланцюгу. Це ваш «старий TTL», який ви маєте перетримати.
4. Визначте TTL для міграції (зазвичай 30–120 секунд) і вимоги до відкату.
5. Знизьте TTL принаймні на один старий-TTL період перед cutover (два, якщо хочете спати).
6. Перевірте на кількох резольверах, що низький TTL тепер саме те, що вони кешують.
7. Перевірте нові endpoint примусовою резолюцією (curl --resolve) і хелсчеками.
8. Зробіть cutover DNS у запланований час. Занотуйте точну зміну, час і серіал.
9. Моніторьте хвіст: трафік на старий endpoint має згаснути протягом кількох TTL-вікон; стежте за помилками і регіональними патернами.
10. Тримайте відкат життєздатним, поки ви ще в періоді «unknown unknowns».
11. Підніміть TTL назад до steady-state, коли вікно відкату закрите і все стабільно.
12. Зробіть постмортем процесу: що вас здивувало (обрізання TTL, кеш застосунків, внутрішні overrides) і додайте це до наступного рукопису.

Операційний чекліст на ніч cutover (те, що ви реально робите)

• Підтвердіть авторитетну відповідь через dig +trace прямо перед зміною.
• Опитайте корпоративні і публічні резольвери та зафіксуйте залишковий TTL.
• Підтвердіть A і AAAA відповіді (або навмисно вимкнений IPv6) відповідно до плану.
• Примусово протестуйте новий endpoint через curl --resolve для TLS і хелсчеків.
• Підтвердіть спостережуваність: логи, метрики і алерти для старого і нового endpoint.
• Зробіть зміну DNS; збільшіть серіал SOA, якщо потрібно.
• Зразу перевірте авторитетні і резольверні відповіді після зміни.
• Спостерігайте помилки клієнтів і трафік на старому endpoint. Не виключайте старий раніше за час хвоста.
• Якщо потрібен відкат — виконуйте швидко, але очікуйте хвіст кешів — комунікуйте це.

Політики (нудні правила, що запобігають «креативним» відмовам)

• Не вводьте зовсім нові хостнейми під час вікна cutover.
• Не ставте надто низькі TTL глобально; обмежуйте їх до критичних для міграції записів.
• Не покладайтеся на поведінку одного резольвера для валідації.
• Не припускайте, що «TTL=60» означає «користувачі перейдуть за 60 секунд».
• Документуйте джерела DNS-відповідей (провайдер авторитетного DNS, внутрішні перегляди, overrides).
• Проводьте аудит кешування DNS у застосунках і повторного використання з’єднань перед міграціями.

FAQ (питання, які почують за п’ять хвилин до cutover)

1) Який TTL слід використовувати під час міграції?

Для конкретних імен, які ви будете переключати: 30–120 секунд у вікні. Але лише після того, як ви знизили TTL завчасно, щоб кеші оновилися.

2) Наскільки рано слід знижувати TTL?

Принаймні на повний старий TTL до cutover; два — якщо хочете більш послідовної поведінки. Якщо старий TTL = 86400, знижуйте за дні, а не «цієї ночі».

3) Чому «DNS propagation» триває довше за TTL?

Бо запис міг бути закешований раніше під старим TTL, деякі резольвери обрізають TTL, а деякі застосунки кешують незалежно. TTL — це максимальний вік кешу від моменту кешування.

4) Чи ставити TTL = 0?

Не робіть цього. Багато систем трактують 0 несподівано, і ви різко піднімете навантаження на DNS-запити. Якщо потрібне майже миттєве керування трафіком — використовуйте балансувальник або service discovery, створені для цього.

5) Чи безпечніший CNAME ніж A-запис для міграцій?

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

6) Чи можемо «скинути кеш інтернету»?

Ні. Ви можете очистити кеші, які контролюєте (ваші резольвери, хости, застосунки), але не чужі. Плануйте хвіст і тримайте старий endpoint живим.

7) Чому деякі користувачі продовжують потрапляти на старий endpoint навіть після того, як кеші мають протухнути?

Довгоживучі з’єднання. Клієнти можуть повторно використовувати TCP-з’єднання хвилинами або годинами. DNS-зміни впливають лише на встановлення нових з’єднань, якщо ви не виконуєте дренаж/закриття.

8) Як валідувати новий endpoint без зміни DNS?

Використайте примусову резолюцію (для HTTPS збережіть hostname для SNI): curl --resolve. Або змініть hosts файл на контрольованому клієнті для тесту, але не плутайте це з поведінкою реального світу.

9) А що з DNSSEC під час міграцій?

DNSSEC підходить, поки ви не міняєте ключі підпису чи провайдерів. Несумісність DS може спричинити широку SERVFAIL. Розглядайте зміни DNSSEC як окрему, ретельно поетапну міграцію.

10) Коли після cutover піднімати TTL назад?

Коли ви спостерігаєте стабільність і вікно відкату закрите. Зазвичай: тримайте низькі TTL кілька годин або день залежно від ризику, потім підніміть до 300–900 секунд.

Висновок: практичні наступні кроки

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

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

1. Виберіть одне критичне ім’я в середовищі і замапте його повний шлях резолюції (включно з AAAA).
2. Зафіксуйте поточні TTL і визначте цільовий TTL для міграції (30–120 секунд для cutover-імен).
3. Проведіть дрил: знизьте TTL завчасно, підтвердіть через dig +trace і кілька резольверів, і виміряйте, як швидко фактично переміщується трафік.
4. Аудитуйте кешування DNS у застосунках і час життя з’єднань. Виправте випадки «фіксує DNS назавжди» до того, як вони зафіксують вас о 3 ранку.
5. Запишіть план швидкої діагностики у ваш on-call runbook і проганяйте його хоча б раз перед справжньою ніччю.

Налаштуйте TTL як профі — і DNS стане передбачуваною частиною міграції, а не страшилкою, яку ви розповідаєте новим співробітникам.