DNS: ваш домен працює… поки раптом ні — пояснення пастки делегування

Делегування: що це насправді означає «по дроту»

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

Делегування — це не ваш файл зони. Делегування — це опублікований батьківською зоною NS-набір для вашого домену,
плюс будь-які glue-записи (A/AAAA у батьку), потрібні для доступу до цих серверів імен.
Ваш файл зони може бути бездоганним, але інтернет усе ще може йти не до тієї двері.

Батьківська і дочірня зона: два джерела істини, які мусять збігатися

Для example.com батьком є .com. Батьківська зона публікує:

• NS-записи у точці делегування: які авторитетні сервери потрібно опитувати.
• Glue-записи (іноді): IP-адреси для серверів імен, що знаходяться всередині делегованої зони (in-bailiwick).
• DS-запис (якщо DNSSEC): зв’язок довіри до DNSKEY дочірньої зони.

Дочірня зона (ваш файл зони на авторитетних серверах) публікує:

• Свій власний NS-набір: кого вона вважає своїми авторитетними серверами.
• Все інше: A/AAAA, MX, TXT, CNAME тощо.
• DNSKEY-записи (якщо DNSSEC) та підписи (RRSIG).

Якщо NS-набір у батька і NS-набір у дитини не збігаються, ви можете потрапити в «розділену делегування»:
деякі резолвери йдуть одним шляхом, деякі — іншим, і кеші закріплюють розбіжність.
Якщо glue неправильний, ви отримаєте правильне ім’я NS, але недосяжну IP. Якщо DS неправильний,
валідатори можуть відкидати відповіді (SERVFAIL) навіть коли записи присутні.

Суха правда: делегування — це розподілена система. Розподілені системи не «поширюють» зміни миттєво, вони
сходяться — іноді повільно, іноді ніколи, поки ви не виправите несумісність.

Чому делегування ламається в продакшні (навіть коли ваша зона ідеальна)

1) UI реєстратора — це не DNS

Інтерфейс вашого реєстратора — це plane керування. Сама делегування живе в реєстрі — в батьківській зоні.
Багато реєстраторів роблять усе правильно. Дехто робить це зрештою. Дехто — після того, як ви натиснете «зберегти» двічі
і дочекаєтесь фонового завдання, яке працює на сервері, що востаннє перезавантажували на бюджетній нараді.

Гірше: реєстратори іноді приймають некоректні стани (наприклад, відсутність glue для in-bailiwick NS),
або нормалізують і переставляють записи так, що це дивує вашу автоматизацію.

2) Glue-записи: «достатня» адресна книга, що може застаріти

Glue існує, щоб розірвати циклічну залежність. Якщо ваш домен — example.com і один із ваших
серверів імен — ns1.example.com, резолвер не може подивитися ns1.example.com
без попереднього резолвінгу example.com. Це рекурсія, що кусає свій хвіст.
Glue — це коли батьківська зона дає IP напряму.

Glue — це також пастка: люди змінюють IP серверів і забувають про glue у батька. Дочірня зона оновлена,
але резолвери продовжують використовувати старий glue. Або ще гірше: лише деякі резолвери так роблять — кеші різні,
і деякі резолвери агресивніше виконують «додаткові» запити.

3) DNSSEC: делегування закривається при помилці

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

4) Негативне кешування: ви виправили, але інтернет усе ще сердиться

Резолвери кешують ні так само завзято, як вони кешують так. Якщо резолвер питав
A www.example.com і отримав NXDOMAIN, він може кешувати цей результат згідно з
негативним TTL (з SOA). Це означає, що ви можете виправити запис і все одно чути від клієнтів, що він не працює,
хвилини чи години по тому.

5) Anycast, балансувальники навантаження та «хитрі» топології NS

Багато авторитетних DNS-провайдерів використовують anycast, що чудово, коли зроблено правильно. Але якщо ви розгортаєте
власні NS і ставите їх за балансувальником, який робить health check по TCP/53, тоді як клієнти здебільшого використовують UDP/53,
ви запрошуєте інцидент.

6) Невідповідність у дочірній зоні: серіали, NOTIFY та приховані майстри

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

Жарт №1: DNS-пропагація — як офісні плітки: усі чують врешті, але не в тому ж порядку і рідко з початковим сенсом.

Факти та історія, що пояснюють сучасні дивності

• 1983: DNS (RFC 882/883, пізніше замінені) був створений, щоб замінити єдиний файл HOSTS.TXT — делегування було функцією масштабування.
• Кореневі сервери не «один сервер»: існує 13 логічних кореневих букв, але кожна з них anycast-ована на багато сайтів у світі.
• Glue навмисно обмежений: батьківські зони надають glue лише для in-bailiwick серверів імен, щоб не ставати загальною адресною книгою.
• Існує перевірка bailiwick для безпеки: резолвери трактують glue по-різному в залежності від того, чи знаходиться воно в межах авторитету, який вони опитують.
• DNS був побудований для UDP: є TCP-fallback, але багато мереж і досі некоректно обробляють TCP/53, що робить великі відповіді (DNSSEC!) крихкими.
• EDNS(0) змінив правила гри: дозволяє більші UDP-пейлоади, але проміжні пристрої іноді викидають фрагментовані UDP, спричиняючи «випадкові» збої.
• DNSSEC (1990-2000-ті): додає підписи й ключі; точка делегування використовує DS, щоб з’єднати батька і дитину довірою.
• TTL — це не обіцянка: це підказка; деякі резолвери обмежують TTL або застосовують локальні політики, тож збіжність складніша, ніж у вашій таблиці.
• NXDOMAIN може бути «дружньо» переписаний: деякі провайдери історично використовували wildcard на рівні TLD або резолвера; у відладці ви можете стикнутися з брехнею.

Одна операційна істина пережила всі еволюції DNS: шлях важить так само, як і дані.
Делегування — це саме шлях.

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

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

Перший крок: визначити, чи це делегування, авторитет чи валідація

1. Перевірте за допомогою trace: Чи знаходить резолвер правильний NS-набір від батька?
   Якщо ні — це делегування (реєстратор/реєстр/glue/DS).
2. Запитайте кожен авторитетний прямо: Чи всі авторитетні сервери відповідають однаково?
   Якщо ні — це консистентність зони/трансфер/роллаут.
3. Перевірте DNSSEC і коди відповідей: SERVFAIL на валідуючих резолверах, але успіх на невалідувальних вказує на проблеми з ланцюжком DNSSEC.

Другий крок: шукайте шаблони «тільки в деяких мережах»

• Працює у одного ISP, не працює в іншого: ймовірно, різниця кешів або різниця валідації DNSSEC.
• Працює по v4, але не по v6: проблеми з AAAA, зламаний v6-glue або недосяжний v6-авторитетний.
• Працює з вашого ноутбука, не працює з регіону моніторингу: будь-якісінг маршрутизації anycast або правила geo-фаєрволу.

Третій крок: вирішіть, чи можна швидко пом’якшити

• Тимчасове пом’якшення: додайте працездатний NS назад у делегування батька; зменшіть радіус ураження.
• Виправлення: скоригуйте glue/DS/NS і дочекайтеся кешів; повідомте очікуваний час відновлення.
• Якщо DNSSEC зламався: або швидко відновіть DS/ключі, або зніміть DS (координовано), але не робіть це напівзаходами.

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

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

Нижче практичні завдання, які можна виконати на Linux-машині. Кожне містить, що каже вивід
і яке рішення з нього випливає. Це не дитячі команди; ними користуються о 2:00 ночі,
коли Slack палає.

Завдання 1: Підтвердити NS-набір делегування у батька (з trace)

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

; <<>> DiG 9.18.24 <<>> +trace example.com NS
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
;; Received 811 bytes from 127.0.0.53#53(127.0.0.53) in 1 ms

com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
;; Received 1171 bytes from 198.41.0.4#53(a.root-servers.net) in 18 ms

example.com.		172800	IN	NS	ns1.dns-host.net.
example.com.		172800	IN	NS	ns2.dns-host.net.
;; Received 212 bytes from 192.5.6.30#53(a.gtld-servers.net) in 22 ms

Що це означає: Показує, що батьківська зона публікує як NS-набір делегування.
TTL тут — це TTL батька, а не вашої зони.

Рішення: Якщо ці NS-імена не ті, що ви очікуєте, перестаньте звинувачувати свої авторитетні сервери.
Виправляйте делегування у реєстратора/реєстру. Якщо вони коректні — перевіряйте glue та консистентність дочірньої зони.

Завдання 2: Перевірити glue у батька (in-bailiwick випадок)

cr0x@server:~$ dig @a.gtld-servers.net example.com NS +norecurse +authority +additional

; <<>> DiG 9.18.24 <<>> @a.gtld-servers.net example.com NS +norecurse +authority +additional
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; AUTHORITY SECTION:
example.com.	172800	IN	NS	ns1.example.com.
example.com.	172800	IN	NS	ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.	172800	IN	A	203.0.113.10
ns2.example.com.	172800	IN	A	203.0.113.11

Що це означає: Батько надає glue A-записи для ns1.example.com/ns2.example.com.
Якщо IP неправильні, резолвери можуть ніколи не дійти до ваших авторитетних серверів.

Рішення: Якщо glue неправильний — оновіть host-об’єкти / glue у реєстратора. Оновлення дочірньої зони цього не виправить.

Завдання 3: Переконатися, що NS-набір дитини збігається з делегуванням батька

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

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

Що це означає: Це те, що дочірня зона стверджує як авторитетні. TTL тут — від вашої зони.

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

Завдання 4: Опитати кожен авторитетний сервер напряму для проблемного запису

cr0x@server:~$ for ns in ns1.example.com ns2.example.com; do echo "== $ns =="; dig @"$ns" www.example.com A +noall +answer; done
== ns1.example.com ==
www.example.com.	300	IN	A	198.51.100.20
== ns2.example.com ==
www.example.com.	300	IN	A	198.51.100.21

Що це означає: Ваші авторитетні сервери не погоджуються. Це не «пропагація»; це несумісність.

Рішення: Виправте доставку зони (AXFR/IXFR, API push, pipeline прихованого майстра), потім перевірте знову. Не переходьте до «чекати».

Завдання 5: Перевірити SOA-серіали на авторитетних серверах

cr0x@server:~$ for ns in ns1.example.com ns2.example.com; do dig @"$ns" example.com SOA +noall +answer; done
example.com.	3600	IN	SOA	ns1.example.com. hostmaster.example.com. 2026020401 7200 3600 1209600 300
example.com.	3600	IN	SOA	ns1.example.com. hostmaster.example.com. 2026020304 7200 3600 1209600 300

Що це означає: Різні серіали означають, що не всі сервери мають одну й ту ж версію зони.

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

Завдання 6: Перевірити DS-запис у батька

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

example.com.	86400	IN	DS	12345 13 2 4C2B9D3C8B4E9B0F0F3E2C2B2D1A9A0D0B2A6F9E6E7C0A1B2C3D4E5F6789

Що це означає: Батько каже, що дитина має валідовуватися цим DS-хешем.

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

Завдання 7: Підтвердити DNSKEY у дитини (і що він там, де ви думаєте)

cr0x@server:~$ dig @ns1.example.com example.com DNSKEY +noall +answer | head -n 3
example.com.	3600	IN	DNSKEY	257 3 13 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
example.com.	3600	IN	DNSKEY	256 3 13 yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy=

Що це означає: Наявність KSK (257) і ZSK (256) записів. Це не доводить правильності, але відсутність — критичний індикатор.

Рішення: Якщо DNSKEY відсутній, але DS існує у батька — очікуйте SERVFAIL від валідаторів. Або опублікуйте DNSKEY/підпишіть зону, або видаліть DS.

Завдання 8: Валідовати як резолвер (перевірити прапорець AD через валідуючий резолвер)

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

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40251
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1
www.example.com.	300	IN	A	198.51.100.20

Що це означає: Прапорець ad вказує, що резолвер вважає відповідь автентифікованою (DNSSEC валідовано).

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

Завдання 9: Порівняти поведінку різних резолверів (виявити «тільки в деяких мережах»)

cr0x@server:~$ for r in 1.1.1.1 8.8.8.8 9.9.9.9; do echo "== $r =="; dig @"$r" www.example.com A +time=2 +tries=1 +noall +answer +comments; done
== 1.1.1.1 ==
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27364
www.example.com.	300	IN	A	198.51.100.20
== 8.8.8.8 ==
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58312
== 9.9.9.9 ==
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11427
www.example.com.	300	IN	A	198.51.100.20

Що це означає: Різні результати вказують на відмінності в валідації, станах кешу або доступності одного anycast-вузла авторитету.

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

Завдання 10: Перевірити усічення UDP (TC біт) і відкат на TCP

cr0x@server:~$ dig @ns1.example.com example.com DNSKEY +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61643
;; flags: qr aa; QUERY: 1, ANSWER: 0
;; WARNING: Message parser reports malformed message packet.

cr0x@server:~$ dig +tcp @ns1.example.com example.com DNSKEY +noall +answer | head -n 2
example.com.	3600	IN	DNSKEY	257 3 13 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
example.com.	3600	IN	DNSKEY	256 3 13 yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy=

Що це означає: Великі DNSSEC-відповіді можуть спричиняти усічення або дивну поведінку проміжних пристроїв. TCP, що працює, коли UDP — ні, — червоний прапорець.

Рішення: Переконайтеся, що авторитетні підтримують EDNS коректно, дозволяють фрагментований UDP, і що TCP/53 доступний. Якщо ви не можете гарантувати UDP, ваша DNSSEC-розгортка буде крихкою.

Завдання 11: Перевірити досяжність NS по UDP і TCP з вашої точки

cr0x@server:~$ nc -vz -u ns1.example.com 53
Connection to ns1.example.com 53 port [udp/domain] succeeded!

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

Що це означає: Це перевіряє базову досяжність. Це не підтверджує коректну DNS-поведінку, але виключає очевидні блокування фаєрволом.

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

Завдання 12: Знайти авторитетний набір, як його бачить рекурсивний резолвер

cr0x@server:~$ dig @1.1.1.1 example.com NS +noall +answer
example.com.	172800	IN	NS	ns1.example.com.
example.com.	172800	IN	NS	ns2.example.com.

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

Рішення: Якщо це відрізняється від того, що показує dig +trace прямо зараз, ви дивитесь на старе кешоване делегування. Ви не зможете очистити світ; плануйте пом’якшення відповідно.

Завдання 13: Проінспектувати поведінку негативного кешування (NXDOMAIN TTL через SOA)

cr0x@server:~$ dig @ns1.example.com example.com SOA +noall +answer
example.com.	3600	IN	SOA	ns1.example.com. hostmaster.example.com. 2026020401 7200 3600 1209600 300

Що це означає: Останнє поле (тут 300) — це негативний TTL кешування (поведінка RFC 2308).

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

Завдання 14: Підтвердити відсутність випадкового CNAME на апексі або заборонених комбінацій

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

cr0x@server:~$ dig @ns1.example.com example.com A +noall +answer
example.com.	300	IN	A	198.51.100.10

Що це означає: Апекс зони не повинен бути CNAME у класичному DNS. Якщо ви бачите CNAME на апексі та одночасно NS/SOA, деякі резолвери поведуться погано.

Рішення: Виправте структуру зони (використовуйте ALIAS/ANAME на рівні провайдера, якщо потрібно) і тримайте стандарти-сумісні відповіді на авторитетних серверах.

Три корпоративні міні-історії з полів делегування

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

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

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

Хибне припущення: «Якщо реєстратор показує нові сервери імен, делегування батька оновлено».
Насправді UI реєстратора був попереду публікації у реєстрі. Деякі рекурсивні резолвери мали в кеші старий NS-набір делегування
з довгим TTL від батька, і вони продовжували питати старого провайдера авторитету — який тепер віддавав старий знімок зони.

Виправлення не було героїчним. Вони тимчасово відновили зону у старого провайдера, щоб обидва шляхи працювали,
потім дочекалися вікна TTL батька. Після стабілізації вони повторно вивели старі авторитетні сервери — цього разу перевіряючи
dig +trace і крос-резолверні перевірки, а не скріншоти.

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

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

Велике підприємство тримало свій авторитетний DNS на парі регіональних балансувальників. Мотив був знайомий:
«Ми зможемо тримати трафік локально, зменшити латентність і мати повний контроль.» Вони також увімкнули DNSSEC на прохання служби безпеки.

В один спокійний тиждень вони «оптимізували» правила фаєрволу: дозволити UDP/53 звідусіль, а TCP/53 — лише з відомих IP резолверів.
Ідея була зменшити експозицію. Це пройшло первинні тести — більшість запитів іде по UDP.

Потім ключовий rollover збільшив розміри відповідей і спричинив більше усічень та відкатів на TCP. Раптом частина резолверів почала таймаутитись.
Вони не були в allowlist’і. Це були легітимні рекурсори з мінливими egress-IP (хмарні резолвери, корпоративні форвардери,
деякі ISP з великими флотами). Користувачі бачили переривчасті збої, що не корелювали з нічим очевидним.

Симптоми були класичними для болю поруч із делегуванням: деякі резолвери працювали, інші отримували SERVFAIL або таймаути, і повторні спроби на іншому NS
іноді вдавалися. Команда витратила години, звинувачуючи DNS-провайдера — але провайдером були вони самі.

Остаточне рішення було непримітним: відкрити TCP/53 ширше, обмежити його розумно й моніторити.
Якщо ви публікуєте DNSSEC, ви не можете робити вигляд, що TCP — опціональний. Ви можете зменшити ризик розумними контролями, але не заперечувати реальність протоколу.

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

Інша компанія мала кілька брендів і доменів, і вони пережили болісний інцидент делегування роками раніше.
Після цього вони запровадили правило: кожна зміна DNS перевіряється автоматизованою «перевіркою здоров’я делегування».
Без виключень. Робота запускалася з кількох мереж і перевіряла батьківські NS, glue, DS, консистентність авторитетних і базову резолюцію.

Одного дня надійшов рутинний запит: «Перенести ns2 на новий IP; стару підмережу виводять з експлуатації.»
Інженер оновив A-запис авторитетної зони для ns2.example.com і новий сервер піднявся.
Все виглядало добре локально.

Автоматизація заблокувала завершення зміни. Вона підняла флаг: «Glue у батькові для ns2.example.com все ще вказує на старий IP.»
Інженер зітхнув, зайшов у реєстратор і оновив host-об’єкт. TTL glue був довгим, тож вони тримали старий IP в роботі до його закінчення.

Результат був нудним, і це найкраще про DNS. Клієнти не помітили нічого. Виведення підмережі відбулося за планом.
Команда не отримала оплесків, але й не отримала постмортему. Оце й перемога.

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

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

1) Симптом: працює з деяких мереж, падає в інших

Корінна причина: Розділене делегування (батьківський NS відрізняється від дитячого NS), або кеші тримають старе делегування з довгим TTL батька.

Виправлення: Використайте dig +trace, щоб підтвердити поточне делегування батька. Зробіть NS-набори батька і дитини ідентичними. Тримайте старий авторитетний з коректними даними, поки TTL батька не спливе.

2) Симптом: переривчасті таймаути, особливо на DNSKEY/TXT

Корінна причина: Проблеми з фрагментацією UDP, EDNS або TCP/53 заблокований. DNSSEC і великі TXT посилюють проблему.

Виправлення: Переконайтеся, що TCP/53 доступний. Налаштуйте авторитетні для EDNS. Зменшіть розмір відповідей де можливо (уникати надмірних TXT, використовувати розумні параметри DNSSEC).

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

Корінна причина: Несумісність DS, відсутній DNSKEY, прострочені підписи або неправильний ланцюг NSEC/NSEC3.

Виправлення: Порівняйте DS у батька з DNSKEY у дитини. Відновіть DS або перепідпишіть зону; якщо потрібно терміново — видаліть DS у батька (координовано), щоб припинити помилки валідації.

4) Симптом: після зміни NS домен «мертвий» годинами

Корінна причина: TTL батька високий; резолвери кешували старе делегування. Або новий авторитетний недосяжний глобально.

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

5) Симптом: IPv6-клієнти падають, IPv4 працює

Корінна причина: Неправильний AAAA-glue для in-bailiwick NS, недоступний v6 на авторитетному або неконсистентна dual-stack маршрутизація.

Виправлення: Перевірте AAAA для NS і v6-досяжність. Якщо ви не можете надійно підтримувати v6 для авторитетного — не публікуйте AAAA для NS.

6) Симптом: різні відповіді залежно від того, на який NS потрапили

Корінна причина: Застарілий вторинний, зламаний трансфер зони або split-brain між провайдерами без дисциплінованого pipeline.

Виправлення: Запровадьте перевірки консистентності SOA-серіалу. Виправте pipeline трансферу. Видаліть нездоровий NS з делегування, поки він не синхронізується.

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

Корінна причина: Негативний TTL кешування утримує NXDOMAIN.

Виправлення: Дочекайтеся закінчення негативного TTL, або якщо потрібне швидше відновлення наступного разу — знизьте мінімальний/негативний TTL у SOA заздалегідь.

8) Симптом: делегування виглядає правильно, але резолвери все одно питають старі NS-імена

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

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

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

Чеклист міграції: змінюємо авторитетного DNS-провайдера без болю

1. Зробіть інвентар поточного делегування: зафіксуйте батьківський NS-набір, glue, DS і TTL за допомогою dig +trace і прямих запитів до батька.
2. Заздалегідь знизьте TTL у дочірній зоні для записів, що змінюватимуться (A/AAAA, CNAME). Не думайте, що це змінить TTL батька.
3. Підготуйте нового провайдера: імпортуйте зону, перевірте всі записи, перевірте статус DNSSEC (вимкнений/увімкнений) свідомо, а не випадково.
4. Тест прямого запиту: опитайте нові авторитетні сервери напряму для критичних імен. Підтвердіть відповіді, SOA і DNSSEC, якщо ввімкнено.
5. Тест досяжності: переконайтеся, що UDP/53 і TCP/53 доступні з інтернету. Перевірте v4/v6 за потреби.
6. Змініть делегування у реєстратора і відразу перевірте dig +trace з кількох точок.
7. Вікно подвійного обслуговування: тримайте старий авторитетний з тими самими відповідями, поки TTL батька і спостережувані кеші резолверів не зійдуться.
8. Моніторте резолюцію, а не лише доступність: моніторте з кількох регіонів і резолверів; ставте оповіщення на сплески NXDOMAIN/SERVFAIL.
9. Лише після цього виводьте старий авторитетний і видаляйте старі NS у дитини й батька.

Чеклист на випадок аварії: «домен частково впав», підозра на делегування

1. Підтвердіть обсяг симптомів: які мережі/резолвери падають? зафіксуйте приклади з точними IP резолверів.
2. Запустіть trace: підтвердьте, що батько делегує прямо зараз.
3. Перевірте glue: якщо in-bailiwick NS, підтвердіть, що glue-адреси батька коректні і доступні.
4. Перевірте консистентність авторитетних: серіал SOA і цільові записи на всіх NS.
5. Перевірте ланцюг DNSSEC: DS у батька проти DNSKEY у дитини; валідуйте через принаймні одного відомого валідуючого резолвера.
6. Мітігейт: якщо один NS зламаний — видаліть його з делегування батька (і з NS-набору дитини) або швидко відновіть; уникайте залишати мертвий NS у ротації.
7. Реалістично повідомляйте: опублікуйте, що ви змінили, і очікуване вікно збіжності на основі TTL і спостережень.
8. Після інциденту: додайте автоматизацію, щоб уникнути повторення (перевірки делегування, досяжність NS, моніторинг термінів DNSSEC).

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

• Тримайте NS-набори батька і дитини ідентичними. Дріфт — це не резервування; це плутанина.
• Маєте принаймні два авторитетні сервери на незалежних мережах/провайдерах, якщо це можливо.
• Моніторте не зсередини вашої мережі, а зовні — зовнішній вигляд резолюції важливіший за внутрішній.
• Відслідковуйте зміни glue як зміни інфраструктури, а не як «вміст DNS».
• Для DNSSEC: моніторьте закінчення підписів, автоматизуйте ротації обережно, і ставтесь до оновлень DS як до продакшн-змін з планом відкату.
• Документуйте процес у реєстратора (хто має доступ і скільки часу займає оновлення).

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

1) Що саме означає «делегування» в DNS?

Делегування — це коли батьківська зона каже резолверам, які сервери імен авторитетні для вашого домену (NS-записи),
плюс glue-IP-и коли потрібно, і DS-записи, якщо увімкнено DNSSEC.

2) Якщо я виправив файл зони, чому користувачі все ще бачать стару поведінку?

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

3) В чому різниця між NS у батька і NS у дитини?

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

4) Коли потрібні glue-записи?

Коли ваше ім’я сервера імен знаходиться всередині домену, який він обслуговує (in-bailiwick), наприклад ns1.example.com для example.com.
Батько має надати glue A/AAAA, щоб резолвери могли дістатися NS без попереднього резолву зони.

5) Чи може неправильний glue зламати все, навіть якщо NS-імена правильні?

Так. Резолвери можуть мати правильні NS-імена, але отримувати неправильну IP-адресу. Ви побачите таймаути або непостійний доступ.
Glue — поширена точка відмови під час перенумерації IP або міграцій провайдера.

6) Чому DNSSEC викликає SERVFAIL замість «неправильної відповіді»?

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

7) Чи існує «DNS-пропагація»?

Не в тому сенсі, в якому люди зазвичай мають на увазі. Немає глобального пушу. Є кешування з TTL, локальні політики резолверів
і багатокроковий шлях запиту. Інтернет сходиться до вашої зміни; він не отримує її миттєво.

8) Як швидко довести, чи це делегування чи мої авторитетні сервери?

Використайте dig +trace, щоб побачити, що делегує батько, потім опитайте кожен авторитетний напряму для проблемного імені.
Якщо trace вказує на неправильні NS/glue/DS — це делегування. Якщо авторитетні не погоджуються — це ваша доставка зони.

9) Чи варто тримати власний авторитетний DNS?

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

10) Скільки серверів імен я маю публікувати?

Два — мінімум; три або чотири допоможуть витривалості, але тільки якщо вони справді незалежні і оновлюються послідовно.
Публікувати п’ять посередніх NS гірше, ніж два відмінні.

Висновок: кроки, що запобігають повторним інцидентам

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

Зробіть це, у такому порядку

1. Побудуйте перевірку здоров’я делегування, яка виконує dig +trace, перевіряє NS/glue/DS у батька і опитує кожен авторитетний на SOA та критичні записи.
2. Забезпечте консистентність NS-наборів між батьком і дитиною. Робіть дріфт сторінкою для пейджингу.
3. Зробіть TCP/53 обов’язковим, якщо ви використовуєте DNSSEC або великі відповіді. Моніторьте UDP і TCP окремо.
4. Практикуйте міграції з вікном подвійного сервісу: тримайте старий авторитетний з коректними даними, поки кеші не зійдуться.
5. Запишіть, хто контролює реєстратора і скільки часу займає оновлення glue/DS. Коли це знадобиться, не буде часу шукати доступи.

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