Моніторинг DNS: оповіщення до того, як помітять користувачі (прості, ефективні перевірки)

Що саме моніторити (і чому DNS вас обманює)

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

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

Чотири шари, що ламаються по‑різному

• Авторитетні сервери імен: ваш набір NS відповідає на запити для зони. Відмови проявляються як SERVFAIL, таймаути, неправильні відповіді, lame делегації, помилки DNSSEC.
• Шар делегації (реєстратор + батьківська зона): батьківська зона вказує на ваші NS і glue. Відмови проявляються як переривчасте резолвінг або повний NXDOMAIN залежно від кешування.
• Рекурсивні резолвери: те, до чого більшість користувачів звертаються (резолвери ISP, публічні резолвери, корпоративні резолвери). Відмови проявляються як затримки, застарілі відповіді або спайки SERVFAIL.
• Поведінка клієнта: додатки роблять власне кешування, деякі ігнорують TTL, деякі віддають перевагу IPv6, хтось по‑іншому рандомно обробляє A і AAAA. Відмови виглядають як «працює на моєму ноуті» інциденти.

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

Цитата, бо це операційно правда: «Hope is not a strategy.» — Vince Lombardi.
Інженери не вигаптували її, але ми точно живемо за нею.

Жарт №1: DNS — як груповий чат: один неправильний учасник (NS запис) — і раптом ніхто вас не знаходить, але якось уся вина на вас.

Цікаві факти про DNS, які важливі під час інцидентів

Деяка «тривіалість» стає дуже практичною, коли ви діагностуєте дивний збій. Ось конкретні факти, які часто з’являються в розборі інцидентів.

1. DNS був стандартизований на початку 1980‑х, щоб замінити центральну модель HOSTS.TXT. Саме тому він децентралізований і кешований за дизайном, і саме через це налагодження є по суті розподіленим.
2. UDP досі є стандартним транспортом для більшості DNS‑запитів, бо це дешево і швидко. Це означає, що втрата пакетів, фрагментація і особливості MTU можуть виглядати як «DNS не працює».
3. EDNS(0) існує, бо класичні DNS–пейлоади були занадто малі. Вони дозволяють резолверам оголошувати більші UDP‑розміри, що взаємодіє з фаєрволами, які не люблять «великі DNS».
4. TCP‑фолбек не опціональний у реальному житті. Усічення (TC=1) змушує переходити на TCP; якщо ваша мережа блокує TCP/53, деякі відповіді будуть періодично відмовлятися.
5. Негативне кешування існує. NXDOMAIN‑відповіді кешуються залежно від негативного TTL у SOA. Коротка некоректна конфігурація може переслідувати вас довше, ніж ви заслуговуєте.
6. TTL — порадник, а не догма. Багато резолверів і клієнтів обмежують TTL (мін/макс), і деякі застосунки кешують довше, ніж слід.
7. Glue‑записи існують, бо сервери імен теж мають імена. Якщо ваші NS іменовані всередині зони, glue у батьківській зоні запобігає циклічній залежності.
8. DNSSEC про автентичність, а не про доступність. Коли воно ламається (поганий DS, прострочені підписи), воно часто відмовляє «жорстко» для валідуючих резолверів і виглядає як випадковий збій.
9. Інфраструктура кореня та TLD сконструйована для стійкості (anycast, масивне розподілення). Більшість інцидентів DNS — самостійно нанесені помилки на шарі делегації або зони.

SLI та дизайн оповіщень, що не марнують ваше життя

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

Вибирайте SLI, які відображають біль користувачів

• Рекурсивний коефіцієнт успіху: відсоток запитів, що повертають валідний ланцюжок A/AAAA/CNAME у межах дедлайну з кількох точок спостереження.
• Рекурсивна затримка: p50/p95 час запиту до рекурсивних резолверів (або ваших власних). Спайки часто передують відмовам.
• Авторитетна доступність: коефіцієнт успіху і затримка при опитуванні кожного авторитетного NS без рекурсії.
• Коректність відповіді: повернуті записи відповідають очікуваним цілям (діапазони IP, CNAME, MX) і очікуваним межам TTL.
• Розподіл RCODE: спайки SERVFAIL, NXDOMAIN, REFUSED — ранні димові сигнали.

Правила оповіщення, які важко ненавидіти

Практичний набір:

• Page при впливовій для користувачів відмові: рекурсивний успіх < 99.5% протягом 5 хвилин у щонайменше двох регіонах для критичних імен.
• Ticket при зростанні затримки: рекурсивний p95 > 250 ms протягом 15 хвилин або раптове 3× збільшення від бази.
• Page при авторитетних помилках: будь‑який авторитетний NS таймаутить > 20% протягом 5 хвилин або виявлено невідповідність SOA/NS.
• Ticket при дрейфі коректності: несподівані зміни IP/CNAME, TTL поза політикою, відсутність AAAA там, де потрібна, підпис DNSSEC, що наближається до закінчення.

Тримайте короткий allowlist «імен, що важливі»: login, api, www, mail і те, що закладено в мобільний застосунок. Моніторте їх як слід.
Потім моніторте здоров’я зони (SOA/NS/DNSKEY) так, ніби саме вас будуть будити, якщо воно зламається. Бо це так і буде.

Прості, ефективні перевірки DNS (з реальними командами)

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

Завдання 1: Підтвердити роботу рекурсивного резолвінгу (еталон)

cr0x@server:~$ dig +time=2 +tries=1 www.example.com A

; <<>> DiG 9.18.24 <<>> +time=2 +tries=1 www.example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5312
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;www.example.com.                IN      A

;; ANSWER SECTION:
www.example.com.         60      IN      A       203.0.113.10

;; Query time: 23 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Dec 31 12:00:00 UTC 2025
;; MSG SIZE  rcvd: 59

Що це означає: Ви отримали NOERROR, A запис і час запиту. Це «еталон, коли більшість речей в порядку».
Рішення: Якщо це не вдається, припиніть гадати. У вас проблема з шляхом до резолвера, а не з додатком.

Завдання 2: Примусово використати відомий публічний резолвер (порівняти шляхи)

cr0x@server:~$ dig @1.1.1.1 +time=2 +tries=1 www.example.com A

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4011
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
www.example.com.         60      IN      A       203.0.113.10
;; Query time: 19 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

Що це означає: Якщо локальний резолвер падає, але публічний резолвер працює, проблема в локальному stub‑резолвері, корпоративному DNS або мережевому шляху.
Рішення: Роутайте до команди, що відповідає за інфраструктуру резолверів/VPN/edge.

Завдання 3: Опитати кожен авторитетний сервер імен напряму (авторитетний DNS живий?)

cr0x@server:~$ dig +norecurse @ns1.example.net example.com SOA

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1209
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123101 3600 600 1209600 300
;; Query time: 14 msec

Що це означає: Прапор aa каже, що сервер є авторитетним і відповідає. Видимий серіал SOA.
Рішення: Якщо один NS таймаутить або повертає інший серіал SOA, ймовірно у вас проблеми з реплікацією/zone transfer або мертвий anycast‑вузол.

Завдання 4: Перевірити, чи всі NS погоджуються щодо SOA серіалу (перевірка консистентності)

cr0x@server:~$ for ns in ns1.example.net ns2.example.net ns3.example.net; do echo "== $ns =="; dig +norecurse +time=2 +tries=1 @$ns example.com SOA +short; done
== ns1.example.net ==
ns1.example.net. hostmaster.example.com. 2025123101 3600 600 1209600 300
== ns2.example.net ==
ns1.example.net. hostmaster.example.com. 2025123101 3600 600 1209600 300
== ns3.example.net ==
ns1.example.net. hostmaster.example.com. 2025123009 3600 600 1209600 300

Що це означає: ns3 відстає (старіший серіал). Це може призводити до різних відповідей залежно від того, який NS опитали.
Рішення: Розглядайте це як інцидент коректності. Виправте розповсюдження зони/трансфер або конвеєр деплою; не кажіть «воно само дозріє».

Завдання 5: Перевірити делегацію від батьківської зони (виявити lame делегацію та проблеми з glue)

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

; <<>> DiG 9.18.24 <<>> +trace example.com NS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21044
...
example.com. 172800 IN NS ns1.example.net.
example.com. 172800 IN NS ns2.example.net.
example.com. 172800 IN NS ns3.example.net.
;; Received 117 bytes from a.gtld-servers.net#53(a.gtld-servers.net) in 28 ms

Що це означає: Ви бачите ланцюжок делегації. Якщо він переривається, зациклюється або вказує на неправильний набір NS, делегація у реєстратора/провайдера неправильна.
Рішення: Якщо NS‑набір у батьківської зони неправильний, зміна вашого zone file не допоможе. Виправляйте делегацію у реєстратора/у провайдера DNS.

Завдання 6: Перевірити CNAME‑ланцюги та «виглядає добре, але ні» відповіді

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

www.example.com. 60 IN CNAME www.example.cdn-provider.net.
www.example.cdn-provider.net. 20 IN A 198.51.100.77

Що це означає: Користувацьке ім’я залежить від DNS іншого домену. Якщо у того провайдера проблеми, ви їх успадковуєте.
Рішення: Моніторте як vanity‑ім’я, так і ціль провайдера. Оповіщуйте про відмови будь‑якого з них, бо користувачам байдуже, чия це вина.

Завдання 7: Виміряти час запиту явно (затримка SLI з shell)

cr0x@server:~$ dig @1.1.1.1 www.example.com A +stats +time=2 +tries=1 | tail -n 5
;; ANSWER SECTION:
www.example.com.         60      IN      A       203.0.113.10

;; Query time: 312 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

Що це означає: 312 ms — високо для багатьох регіонів. Це може бути тимчасово або від втрати пакетів, що змушує повтори.
Рішення: Якщо p95 росте, не чекайте SERVFAIL. Почніть перевірку MTU шляху, змін фаєрвола, навантаження резолвера і поведінки EDNS.

Завдання 8: Виявити усічення і проблеми з TCP‑фолбеком

cr0x@server:~$ dig @8.8.8.8 DNSKEY example.com +dnssec +time=2 +tries=1

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6512
;; flags: qr rd ra tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: Message truncated

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

Завдання 9: Тест DNS через TCP явно (підтвердити, що фаєрвол не їсть його)

cr0x@server:~$ dig +tcp @8.8.8.8 DNSKEY example.com +dnssec +time=2 +tries=1 +stats | tail -n 6
;; ANSWER SECTION:
example.com.  1800 IN DNSKEY 257 3 13 rX9W...snip...
example.com.  1800 IN DNSKEY 256 3 13 dE2Q...snip...

;; Query time: 41 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (TCP)

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

Завдання 10: Перевірити поведінку негативного кешування (NXDOMAIN, що «прилипає»)

cr0x@server:~$ dig +noall +authority does-not-exist.example.com A

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

Що це означає: NXDOMAIN‑відповіді містять SOA зони; останнє поле (тут 300) — негативний TTL для кешування.
Рішення: Якщо ви випадково видалили запис і повернули його, очікуйте, що деякі клієнти будуть і далі падати до закінчення негативного TTL. Плануйте зміни відповідно.

Завдання 11: Підтвердити DNSSEC за допомогою валідуючого інструмента (відділити «DNS працює» від «DNS валідний»)

cr0x@server:~$ delv @1.1.1.1 example.com A

; fully validated
example.com. 300 IN A 203.0.113.20

Що це означає: «fully validated» означає, що ланцюг DNSSEC проходить від trust anchors.
Рішення: Якщо валідація не проходить — розглядайте як високий пріоритет для користувачів за валідуючими резолверами (багато корпоративних мереж). Швидко фіксуйте DS/DNSKEY/RRSIG.

Завдання 12: Виявити надто низькі TTL (самонанесений трафік і джиттер)

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

api.example.com. 5 IN A 203.0.113.44

Що це означає: TTL 5 секунд — це фактично «будь ласка, DDoS‑те мої авторитетні сервери легітимним трафіком».
Рішення: Підвищіть TTL до розумного рівня для стабільних кінцівок (зазвичай 60–300 секунд для динамічних front door, довше для статичних). Низький TTL — лише за наявності плану.

Завдання 13: Перевірити поведінку для кількох записів (A та AAAA можуть падати незалежно)

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

www.example.com. 60 IN A 203.0.113.10
www.example.com. 60 IN AAAA 2001:db8:abcd::10

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

Завдання 14: Перевірити несподіванки split‑horizon (внутрішні vs зовнішні відповіді)

cr0x@server:~$ dig @10.0.0.53 www.example.com A +noall +answer
www.example.com. 60 IN A 10.20.30.40

Що це означає: Внутрішній резолвер повертає приватний IP. Це може бути правильно (внутрішня маршрутизація) або катастрофічно (витік приватної відповіді назовні).
Рішення: Підтвердіть, що views навмисні. Додайте моніторинг зсередини і ззовні мережі, щоб переконатися, що кожній аудиторії повертається потрібна відповідь.

Завдання 15: Підтвердити ідентичність авторитетного сервера (чи потрапляєте ви на правильний вузол?)

cr0x@server:~$ dig +norecurse @ns1.example.net version.bind TXT chaos +short
"ns1-anycast-pop3"

Що це означає: Якщо ввімкнено, це допомагає ідентифікувати конкретний anycast POP, до якого ви підключилися. Не всі провайдери це дозволяють — і це нормально.
Рішення: Використовуйте це, щоб корелювати помилки з конкретним POP або бекендом. Якщо вимкнено, не ламайтеся; опирайтеся на затримку, traceroute і провайдерські інструменти.

Завдання 16: Захоплювати RCODE і таймаути в масштабі (перетворити ad‑hoc перевірки на метрики)

cr0x@server:~$ for i in $(seq 1 20); do dig @1.1.1.1 +time=1 +tries=1 www.example.com A +noall +comments; done | egrep "status:|Query time:"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34325
;; Query time: 18 msec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2462
;; Query time: 21 msec
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 991
;; Query time: 1001 msec

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

Жарт №2: DNS‑кешування — єдине місце, де «працювало п’ять хвилин тому» — це функція дизайну, а не признання провини.

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

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

Перший: Це проблема користувацького досвіду чи авторитетна?

1. Опитайте публічний рекурсивний резолвер з щонайменше двох мереж. Якщо він повсюдно падає, ймовірно проблема авторитетна/делегація або DNSSEC.
2. Опитайте ваш авторитетний NS напряму з +norecurse. Якщо авторитетна відповідь нормальна, а рекурсія падає — проблема в екосистемі резолверів (або валідація DNSSEC).
3. Перевірте розподіл RCODE: NXDOMAIN проти SERVFAIL проти таймауту. Кожен вказує на різні причини.

Другий: Визначте клас відмови

• Таймаути: мережевий шлях, фаєрвол, помилкове DDoS‑захист, проблема anycast POP, втрата пакетів вгорі.
• SERVFAIL: відмова валідації DNSSEC, пошкоджена авторитетна відповідь, резолвер не може досягти NS, lame делегація, відмова бекенда.
• NXDOMAIN: запис відсутній, деплой неправильного файлу зони, помилка в імені, негативне кешування, помилки з suffix.
• Неправильна відповідь: застаріла зона на одному NS, витік view, погана автоматизація, зміна CNAME цілі, скомпрометована конфігурація.

Третій: Визначте, де саме в ланцюжку відбувається збій

1. Запустіть +trace, щоб побачити делегацію і де вона зупиняється.
2. Порівняйте SOA‑серіали по всіх авторитетних NS. Невідповідні серіали пояснюють «лише деякі користувачі».
3. Тестуйте UDP і TCP (особливо для DNSKEY/великих відповідей). Усічення + блокований TCP — класика.
4. Валідуйте DNSSEC за допомогою delv. Якщо валідація падає, ваша зона може виглядати «добре» для невалідуючих резолверів, але корпоративні користувачі не зможуть вас розв’язати взагалі.

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

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

Міні‑історія 1: Відмова через хибне припущення

Середній SaaS‑провайдер мігрував свій маркетинговий сайт на новий CDN. Зміна була проста: замінити A запис на CNAME,
знизити TTL для переключення і вважати роботу завершеною. Інженер припустив, що «якщо CNAME резолвиться у мене, він резолвиться у всіх».
Це припущення завершило багато спокійних вечорів.

Переключення виглядало добре з офісної мережі. Воно виглядало добре з публічного резолвера. Але корпоративні клієнти почали скаржитися:
браузери зависали деякий час, а потім здавалися. Канал інцидентів наповнився скриншотами й здогадками. Додаток був здоровий; origin був здоровий; TLS був здоровий.
Єдиним спільним фактором було «не вдалося дістатися сайту».

Виявилося, що цільове ім’я CDN повертало великий набір записів з DNSSEC, що спричинило усічення. Деякі корпоративні мережі дозволяли UDP/53, але блокували TCP/53
(так, буває й досі). Для таких користувачів рекурсивний резолвер бачив TC=1, пробував TCP, отримував блокування і повертав SERVFAIL. Домашні користувачі цього не помічали, бо їхні резолвери могли використовувати TCP.

Виправлення було не у веб‑стеку. Це була політика і моніторинг: тестувати DNS через TCP у синтетичних перевірках, моніторити рівні SERVFAIL з «корпоративних» точок спостереження,
і додати префлайт‑крок «чи збільшує ця зміна розмір відповіді або складність DNSSEC». Припущення померло. Продакшн став кращим.

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

Інша компанія тримала власний авторитетний DNS на парі anycast‑кластерів. Хтось помітив помітну затримку при «холодних» запитах
і вирішив «оптимізувати DNS», встановивши TTL 10 секунд по всій зоні. Теорія: швидше переключення під час інцидентів і швидші розгортання.
Реальність: DNS не система фіч‑флагів. Це множник навантаження.

Це не вибухнуло відразу. І це найгірше. Кілька днів усе відчувалося швидшим під час релізів і зміна отримала похвалу як «більш динамічна».
Потім звичайне нарощення трафіку вдарило: не DDoS, просто нормальний ріст і маркетинг‑кампанія. Кеші резолверів постійно спливали, обсяг запитів до авторитетних серверів зріс,
anycast‑кластери почали скидати пакети під піковим навантаженням. Таймаути збільшилися, потім повто́ри, а потім повто́ри створили ще більше навантаження. Класичне петлеве підсилення.

Користувачі зазнавали переривчастих збоїв, які було важко відтворити. Дехто мав кешовані відповіді; інші були непощадні. Моніторинг, що перевіряв лише одного резолвера
і одне ім’я, пропустив ранні попередження. Занадто довго зв’язували точки: «оптимізація» зробила DNS залежним від ідеальної авторитетної продуктивності.

Відкат був простим: відновити розумні TTL (60–300 секунд для front door; довше, де можливо), і додати алертинг за QPS та рівнями помилок авторитетних серверів.
Вони також зберегли невелику кількість низькоттлових записів для реальних сценаріїв переключення, під контролем змін. Урок: оптимізуйте заради стійкості, а не заради хайпу швидких змін.

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

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

Одної п’ятниці команда додала нове внутрішнє ім’я хоста для сервісу. Зміна мала з’явитися лише у внутрішньому view,
але змінна шаблону була неправильно встановлена. Запис додали і в зовнішню зону теж, вказавши на приватну адресу RFC1918.
Якби це потрапило в широкий доступ, зовнішні користувачі намагалися б підключитися до нерутованої приватної IP — у кращому випадку таймаут, у гіршому — доступ до чогось небажаного у їхній мережі.

Префлайт‑перевірки спрацювали за хвилини. Зовнішня перевірка помітила приватний A запис і голосно зламалася. Зміну відкотили до того, як кеші широко розповсюдилися.
Тікет інциденту ніколи не став клієнтським інцидентом. Команда змогла насолоджуватися вихідними — і це справжній KPI SRE.

Нудна практика не була винахідливою. Це була просто конкретна, повторювана валідація, що відповідала відомим режимам відмов. Вона не запобігла помилкам.
Вона не дала помилкам перерости в відмови.

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

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

1) Симптом: «Працює у мене, зламано для користувачів»

• Корінна причина: кешовані відповіді у вашій мережі; деякі резолвери ще мають старі дані; несумісні авторитетні NS; різниця split‑horizon.
• Виправлення: порівняйте SOA‑серіали по всіх авторитетних NS; опитайте кілька рекурсивних резолверів; знижуйте TTL перед плановими міграціями, а не під час інцидентів.

2) Симптом: Переривчасті SERVFAIL, особливо в корпоративних мережах

• Корінна причина: відмова валідації DNSSEC (прострочені RRSIG, неправильний DS), або усічення з потребою TCP, який блокується.
• Виправлення: запустіть delv для валідації; тестуйте dig +tcp; виправте процеси ротації DS/DNSKEY; забезпечте роботу TCP/53 end‑to‑end.

3) Симптом: Спайки NXDOMAIN після деплою

• Корінна причина: запис видалено/перейменовано; деплоївся неправильний файл зони; опечатка в імені; негативне кешування подовжує вплив.
• Виправлення: відновіть запис; підтвердіть інкремент серіалу SOA; розумійте негативний TTL у SOA; моніторте частоту NXDOMAIN по імені.

4) Симптом: Повільний резолвінг, але не падає

• Корінна причина: втрата пакетів; перевантажені резолвери; проблеми з підключенням вгорі; EDNS UDP‑розмір викликає повтори/фолбек.
• Виправлення: виміряйте p95 затримки; тестуйте з різних резолверів; перевірте усічення; налаштуйте розмір буфера EDNS, якщо володієте резолверами; виправляйте мережеві втрати.

5) Симптом: Ламаються лише IPv6‑користувачі (або деякі мобільні мережі)

• Корінна причина: битий AAAA‑запис або битий IPv6‑маршрут; клієнти віддають перевагу IPv6; асиметрична досяжність.
• Виправлення: моніторте AAAA окремо; перевірте доступність IPv6‑кінцівок; тимчасово видаліть AAAA, якщо не можете його підтримувати (з планом).

6) Симптом: Один конкретний запис падає, все інше в порядку

• Корінна причина: проблема з CNAME‑ціллю; надто великий запис; неправильний тип запису; взаємодія з wildcard.
• Виправлення: моніторте і тестуйте весь ланцюжок; тримайте набори записів компактними; уникайте хитромудрих wildcard‑налаштувань, якщо не подобається розгадувати загадки.

7) Симптом: Деякі резолвери отримують REFUSED

• Корінна причина: ACL на авторитетних серверах; занадто агресивне обмеження швидкості; геоблокування; неправильно налаштовані views.
• Виправлення: перегляньте ACL і політику відповідей; налаштуйте RRL; тестуйте з кількох регіонів; не блокуйте рекурсивні резолвери, які ви не контролюєте, якщо це не вимагається законом.

8) Симптом: Зміни в зоні «випадково» відкатуються або відрізняються по NS

• Корінна причина: кілька джерел істини; часткові деплоси; зламана NOTIFY/AXFR/IXFR; ручні правки на одному вузлі.
• Виправлення: забезпечте єдине джерело істини; автоматизуйте деплои; перевіряйте зони по всіх NS; оповіщуйте при невідповідності SOA негайно.

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

A. Побудуйте мінімальний набір моніторингу DNS (один вечір, без драм)

1. Виберіть 5–10 критичних імен: www, api, login, mail, а також мобільні кінцеві точки.
2. Для кожного імені визначте очікувані відповіді: діапазони A/AAAA, цілі CNAME, хости MX, межі TTL.
3. Запустіть рекурсивні перевірки принаймні з двох мереж (регіон хмар A і B; або хмара + on‑prem).
4. Запустіть авторитетні перевірки до кожного NS напряму з +norecurse.
5. Оповіщайте про відмови: таймаути, SERVFAIL, неправильні відповіді і невідповідність серіалів SOA.
6. Дашбордьте RCODE і затримку по імені, а не лише агреговано по всій зоні.

B. Зробіть DNS‑зміни безпечнішими (план «не бути хитрим»)

1. Знижуйте TTL завчасно перед плановими міграціями (години‑день до), а не під час інциденту.
2. Використовуйте поетапні релізи: спочатку канаркове ім’я (наприклад, canary-api).
3. Двоперспективна валідація: внутрішні та зовнішні відповіді мають бути навмисно різними, а не випадково.
4. Двоперспективна рекурсивна валідація: тестуйте і корпоративний шлях, і публічний резолвер.
5. Дисципліна SOA‑серіалів: забезпечте монотонні серіали і оповіщення при невідповідності по NS.
6. Гігієна DNSSEC: відстежуйте прострочення підписів і ротацію DS/DNSKEY за допомогою явних рукописів.

C. Маршрутизація оповіщень для продакшну

1. Page тим, хто може це виправити: команда провайдера DNS, мережна команда або платфорна. Якщо по оповіщенню не можуть діяти — це шум.
2. Включайте негайні команди в оповіщення: «Запустіть dig +trace», «Опитайте кожен NS за SOA», «Запустіть delv».
3. Включайте очікуване vs фактичне в навантаження оповіщення: деталі невідповідності записів, значення TTL і які резолвери впали.
4. Корелюйте з вікнами змін: інциденти DNS часто корелюють зі змінами; ваше оповіщення має показувати недавні пуші DNS.

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

1) Моніторити DNS з VPC, з публічного інтернету чи обидва?

Обидва. Внутрішня перспектива ловить помилки split‑horizon і проблеми резолвера у вашому середовищі. Зовнішня відображає те, що бачать клієнти. Одна точка зору — це шлях до несподіванок.

2) Яка найцінніша перевірка DNS?

Опитування кожного авторитетного сервера за SOA й порівняння серіалів. Це найшвидший спосіб виявити часткові деплои, зламані трансфери і інциденти «лише деякі користувачі».

3) Хіба «dig з одного хоста» недостатньо?

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

4) Як оповіщати про «пропагацію» проблеми?

Припиніть називати це пропагацією і називайте справжнє: несумісний авторитетний стан або невідповідність делегації. Оповіщуйте про невідповідність SOA серіалів і про різниці відповідей по NS.

5) Наскільки низьким має бути TTL для фронта балансувальника навантаження?

Зазвичай 60–300 секунд. Нижчий TTL лише якщо у вас є перевірена процедура відкату і авторитетна здатність обслуговувати підвищений QPS. «5 секунд всюди» — запах ненадійності.

6) Чому я бачу SERVFAIL, коли авторитетний сервер здається нормальним?

Часто це DNSSEC валідація, що падає на резолвері, або резолвер не може дістатися до одного з ваших NS через мережеві проблеми. Тестуйте за допомогою delv і опитуйте кожен NS напряму.

7) Чи справді потрібно піклуватися про TCP/53?

Так. DNSKEY‑відповіді, великі TXT і DNSSEC можуть спричинити усічення. Якщо TCP блокується, деякі резолвери відмовляють. Моніторте UDP і TCP шляхи.

8) Як автоматично виявляти «неправильні відповіді»?

Визначте очікувані значення: цілі CNAME, діапазони IP і межі TTL. Потім запускайте синтетичні запити і дифайте секцію відповіді. Оповіщуйте про дрейф, а не лише про відмови.

9) А як щодо DNS over HTTPS (DoH) і DNS over TLS (DoT)?

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

10) Скільки імен слід моніторити, щоб не потонути в оповіщеннях?

Почніть з 5–10 критичних імен плюс перевірки здоров’я зони. Розширюйте лише тоді, коли зможете пояснити, яку дію викликає кожне оповіщення. Моніторинг — це не колекціонування штампів.

Висновок: наступні кроки, які ви можете зробити цього тижня

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

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

1. Реалізуйте перевірки консистентності SOA‑серіалів по всіх авторитетних NS і оповіщайте про невідповідність.
2. Додайте рекурсивні перевірки з двох мереж і оповіщуйте про стійку частоту відмов і p95‑затримку.
3. Додайте UDP+TCP DNS‑перевірки для щонайменше одного запиту з великою нагрузкою DNSSEC (DNSKEY), щоб виявити усічення/блокування TCP.
4. Визначте очікувані відповіді та політику TTL для критичних імен і оповіщуйте про дрейф.
5. Напишіть односторінковий runbook швидкої діагностики DNS за розділом‑плейбуком вище і прикріпіть його до оповіщень.

Якщо ви зробите хоча б це, ви зловите більшість DNS‑відмов до того, як їх помітять ваші клієнти. А якщо пощастить — раніше, ніж ваш CEO.