DNS SERVFAIL від постачальника: як довести, що проблема на їхньому боці

Що насправді означає SERVFAIL (і чого це не означає)

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

SERVFAIL — це не NXDOMAIN

NXDOMAIN — це чітке «не існує». SERVFAIL — це «щось завадило мені прийняти рішення». Ставтеся до них по‑різному. NXDOMAIN — це дані. SERVFAIL — це інцидент надійності.

SERVFAIL може бути вашою помилкою, навіть якщо виглядає як upstream

Якщо ви форвардите всі запити до провайдера й локальний кеш‑резольвер налаштований як чистий форвардер, ви створили єдину точку звуження. Коли upstream резольвер поводиться некоректно, ваш локальний сервер повертає SERVFAIL і ви відчуваєте, що втрачаєте розум. Але корінь проблеми може бути вашим вибором архітектури: відсутність fallback, відсутність диверсифікації, неправильний MTU, зламані DNSSEC trust‑anchors або надто жорстка політика.

Ми тут не для філософств. Ми тут, щоб довести, де знаходиться помилка і що з нею робити.

Жарт №1: DNS — єдина система, де «в кеші» може означати «все добре», «зламано» або «зламано по‑іншому».

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

Перший: вирішіть, локальна це проблема, upstream рекурсивна чи авторитетна

• Запитайте ваш локальний резольвер (той, який насправді використовують хости). Якщо він повертає SERVFAIL — продовжуйте.
• Запитайте відомий надійний публічний резольвер з того самого хоста. Якщо там працює, домен, ймовірно, в порядку, а підозра падає на ваш upstream‑шлях.
• Прослідкуйте до авторитетного (некурсивний «walk»). Якщо авторитетні відповіді здорові, скоріш за все проблема в рекурсії/валідації upstream.

Другий: відмежуйте помилки DNSSEC від транспортних проблем та політичних блокувань

• DNSSEC: SERVFAIL на валідувальних резольверах; працює з +cd (checking disabled) або з невалідувальними резольверами.
• Транспорт/MTU/фрагментація: UDP‑відповіді обриваються або губляться; fallback на TCP не спрацьовує; переривчасто залежить від мережевого шляху.
• Політика/RPZ/фільтрація: сталий SERVFAIL/NXDOMAIN тільки на резольверах провайдера; інші резольвери успішні; іноді провайдер визнає «безпекову фільтрацію».

Третій: зберіть докази з часом, IP резольверів і пакетних трас

• Занотуйте точну IP‑адресу резольвера, що повернув SERVFAIL, часові відмітки, ім’я/тип запиту і чи намагалися TCP.
• Зберіть вивід dig з +stats і +dnssec.
• Запустіть короткий цілеспрямований tcpdump, щоб показати upstream‑відповіді (або їх відсутність).

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

Факти й історія, які важливі під час реальних інцидентів

1. DNS існує довше за веб. Він був створений на початку 1980‑х як розподілена база даних для заміни HOSTS.TXT; припущення щодо надійності були… оптимістичні.
2. RCODE 2 (SERVFAIL) завжди був навмисно нечітким. Протокол не хотів розкривати внутрішні подробиці, що зручно для простоти й погано для інцидент‑респонсу.
3. EDNS0 (1999) змінив моди відмов. Більші UDP‑пакети зменшили використання TCP, але додали проблеми фрагментації/MTU, які досі викликають «випадкові» SERVFAIL/таймаути.
4. DNSSEC (2000‑ті) зробив «цілісність даних» пріоритетною. Це також зробило «досяжні домени» неуспішними при валідації, коли підписів, DS‑записів або годинника не вистачає чи вони неправильні.
5. Негативне кешування стало стандартною поведінкою. Кешування NXDOMAIN і інших негативних відповідей покращує продуктивність, але може продовжити біль після виправлення, якщо TTLи великі.
6. Anycast‑резольвери ускладнили дебаг. «8.8.8.8» — це не одна коробка; резольвери провайдерів теж часто anycast‑ні, тому поведінка може відрізнятися за географією й часом.
7. Glue‑записи регулярно спричиняють інциденти. Делегації, що залежать від glue, можуть ламатися тонкими способами при некоректних оновленнях регістратора/батьківської зони.
8. TCP‑fallback для DNS в практиці не опційний. Фаєрволи, що блокують DNS через TCP, створюють відмови, які виглядають як upstream SERVFAIL.
9. Резольвери реалізують політики. RPZ, блокування шкідливого ПЗ, «фільтри для сімей» і корпоративні політики можуть перетворити звичайний запит у SERVFAIL або NXDOMAIN — цілком навмисно.

Ментальна модель: stub → recursive → authoritative

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

• Stub‑резольвер: бібліотека клієнта на хості (часто через systemd-resolved), яка просить когось іншого виконати рекурсію.
• Рекурсивний резольвер: ваш кешуючий/валідувальний сервер (Unbound, BIND, Knot Resolver) або керований резольвер провайдера, що виконує рекурсію і кешує відповіді.
• Авторитетні сервери: сервери для домену, що відповідають із даних зони (часто за DNS‑провайдерами, балансувальниками навантаження і anycast).
• Батьківська зона: делегація і DS‑записи знаходяться над вами (.com, .net тощо). Багато «проблем авторитетних» насправді — проблеми батьківської/реєстраційної частини.

«SERVFAIL від upstream» зазвичай означає: ваш stub запитав рекурсивний, рекурсивний запитав свій upstream‑форвардер. Той upstream‑форвардер повернув SERVFAIL або пройшов таймаут. Ваш рекурсивний потім повернув SERVFAIL до stub. Завдання — довести, який саме хоп зазнав невдачі і чому.

Одна перефразована ідея, часто приписувана лідеру операцій: «Сподівання — не стратегія; міряйте й перевіряйте.» (перефразована ідея, Gene Kim)

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

Ці завдання створені для побудови ланцюга доказів. Виконуйте їх з: (1) ураженого хоста, (2) хоста в іншому сегменті мережі та бажано (3) з чистої точки поза вашим провайдером, наприклад маленької VM.

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

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54

Що це означає: Ваш хост відправляє DNS на 10.0.0.53/10.0.0.54. Це ваші перші підозрювані, а не «інтернет» загалом.

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

Завдання 2: Відтворіть SERVFAIL проти того резольвера, який використовується

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

; <<>> DiG 9.18.24 <<>> @10.0.0.53 www.example.com A +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41277
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUERY SECTION:
;www.example.com.                IN      A

;; Query time: 58 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Tue Dec 31 12:04:55 UTC 2025
;; MSG SIZE  rcvd: 40

Що це означає: Резольвер повернув SERVFAIL швидко (58 ms). Це не типовий таймаут; це активний шлях відмови.

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

Завдання 3: Порівняйте з відомим надійним публічним резольвером з того самого хоста

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

; <<>> DiG 9.18.24 <<>> @1.1.1.1 www.example.com A +stats
; (1 server found)
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5013
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com.         300     IN      A       93.184.216.34

;; Query time: 14 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Tue Dec 31 12:05:08 UTC 2025
;; MSG SIZE  rcvd: 60

Що це означає: Домен резолюється нормально в іншому місці. Це відводить підозру від авторитетного аутейджу і вказує на поведінку вашого рекурсивного шляху/провайдера.

Рішення: Почніть будувати доказ «тільки ці IP‑адреси резольверів падають».

Завдання 4: Перевірте, чи пов’язано це з DNSSEC (класична пастка SERVFAIL)

cr0x@server:~$ dig @10.0.0.53 www.example.com A +dnssec +multi

; <<>> DiG 9.18.24 <<>> @10.0.0.53 www.example.com A +dnssec +multi
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60172
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Що це означає: Все ще SERVFAIL. Ще не остаточно.

Рішення: Спробуйте +cd (checking disabled). Якщо це працює, ймовірно, у вас помилка валідації DNSSEC на upstream‑шляху.

Завдання 5: Запитайте з відключеною перевіркою, щоб ізолювати помилки валідації

cr0x@server:~$ dig @10.0.0.53 www.example.com A +cd +stats

; <<>> DiG 9.18.24 <<>> @10.0.0.53 www.example.com A +cd +stats
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28212
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com.         300     IN      A       93.184.216.34

;; Query time: 31 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Tue Dec 31 12:06:01 UTC 2025
;; MSG SIZE  rcvd: 60

Що це означає: Із відключеною перевіркою DNSSEC відповідає. Це сильно вказує на помилку валідації DNSSEC у резольверному ланцюгу (trust anchor, некоректний DS, прострочені підписи, зсув годинника або баг upstream).

Рішення: Зберіть докази ланцюга DNSSEC і перевірте логи резольвера; підготуйтеся сказати провайдеру «валідатор працює некоректно», а не «DNS недоступний».

Завдання 6: Пройдіть делегаційну ланку за допомогою trace (доказ авторитетного шляху)

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

; <<>> DiG 9.18.24 <<>> +trace www.example.com A
.                       518400  IN      NS      a.root-servers.net.
...
com.                    172800  IN      NS      a.gtld-servers.net.
...
example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.
www.example.com.        300     IN      A       93.184.216.34

Що це означає: Ви можете дістатися авторитетного ланцюга й отримати A‑запис. Це ваш «квиток», що авторитетні відповіді в порядку.

Рішення: Якщо +trace працює стабільно, а резольвер провайдера повертає SERVFAIL, у вас сильний кейс на upstream‑резольвер.

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

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

; <<>> DiG 9.18.24 <<>> @203.0.113.53 www.example.com A +stats
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1400
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; Query time: 22 msec
;; SERVER: 203.0.113.53#53(203.0.113.53) (UDP)
;; WHEN: Tue Dec 31 12:06:44 UTC 2025
;; MSG SIZE  rcvd: 40

Що це означає: Конкретна upstream IP‑адреса рекурсивного резольвера повернула SERVFAIL швидко. Це золото для ескалації: точно й відтворювано.

Рішення: Повторіть запит до вторинних резольверів провайдера. Якщо лише один падає, скоріш за все ви натрапили на будькаст‑POP або частковий аутейдж.

Завдання 8: Перевірте, чи працює TCP‑fallback (підозра на фрагментацію/MTU)

cr0x@server:~$ dig @203.0.113.53 www.example.com DNSKEY +tcp +dnssec +stats

; <<>> DiG 9.18.24 <<>> @203.0.113.53 www.example.com DNSKEY +tcp +dnssec +stats
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32999
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 35 msec
;; SERVER: 203.0.113.53#53(203.0.113.53) (TCP)
;; WHEN: Tue Dec 31 12:07:18 UTC 2025
;; MSG SIZE  rcvd: 1102

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

Рішення: Якщо TCP працює, а UDP ні — фокусуйтеся на MTU/EDNS0 та мережевому фільтруванні, а не на «сервер впав».

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

cr0x@server:~$ dig @203.0.113.53 www.example.com A +bufsize=1232 +stats

; <<>> DiG 9.18.24 <<>> @203.0.113.53 www.example.com A +bufsize=1232 +stats
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49811
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com.         300     IN      A       93.184.216.34

;; Query time: 20 msec
;; SERVER: 203.0.113.53#53(203.0.113.53) (UDP)
;; WHEN: Tue Dec 31 12:07:47 UTC 2025
;; MSG SIZE  rcvd: 60

Що це означає: З консервативним розміром буфера запит успішний. Це вказує на фрагментацію/PMTUD‑проблеми між вами і резольвером або між резольвером і авторитетними серверами.

Рішення: Можливо, провайдер у порядку, але мережевий шлях (можливо їхній edge) кидає фрагменти. Це все ще їхня відповідальність, але тепер ви можете описати проблему пакетами, а не відчуттями.

Завдання 10: Перевірте конфігурацію локального кеш‑резольвера/форвардера (приклад Unbound)

cr0x@server:~$ sudo unbound-control status
version: 1.19.0
verbosity: 1
threads: 2
modules: 2 [ subnetcache validator ]
uptime: 38122 seconds
options: control(ssl)
unbound (pid 1221) is running...

Що це означає: Unbound валідуючий (завантажено модуль validator). Якщо upstream падає лише на валідувальні запити, це має значення.

Рішення: Якщо ви форвардите до валідувального upstream і одночасно валідуєте локально — не робіть так. Виберіть одну точку валідації і зробіть її передбачуваною.

Завдання 11: Перевірте логи резольвера на помилки валідації (systemd‑journald)

cr0x@server:~$ sudo journalctl -u unbound --since "10 min ago" | tail -n 8
Dec 31 12:05:59 server unbound[1221]: info: validation failure <www.example.com. A>: signature expired
Dec 31 12:06:00 server unbound[1221]: info: error: SERVFAIL <www.example.com. A>: validation failure

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

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

Завдання 12: Перевірте синхронізацію часу (DNSSEC дуже чутливий)

cr0x@server:~$ timedatectl
               Local time: Tue 2025-12-31 12:08:21 UTC
           Universal time: Tue 2025-12-31 12:08:21 UTC
                 RTC time: Tue 2025-12-31 12:08:21
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Що це означає: Годинник синхронізовано. Добре. Один не наш самоспрост.

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

Завдання 13: Перевірте, чи не блокується TCP/53 (локально або мережею)

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

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

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

Завдання 14: Захоплення пакетів, щоб довести поведінку upstream

cr0x@server:~$ sudo tcpdump -ni eth0 host 203.0.113.53 and port 53 -vv -c 6
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:09:01.120001 IP 10.0.1.20.53422 > 203.0.113.53.53: 41277+ A? www.example.com. (33)
12:09:01.141883 IP 203.0.113.53.53 > 10.0.1.20.53422: 41277 ServFail 0/0/1 (40)
12:09:02.001220 IP 10.0.1.20.39511 > 203.0.113.53.53: 5013+ A? www.example.com. (33)
12:09:02.015430 IP 203.0.113.53.53 > 10.0.1.20.39511: 5013 1/0/1 A 93.184.216.34 (60)
6 packets captured
6 packets received by filter
0 packets dropped by kernel

Що це означає: У вас є пронумерований, затайм‑штампований запис «on‑wire», що резольвер провайдера іноді віддає SERVFAIL, а іноді — успіх. Якщо поведінка переривчаста, це те, як довести, що вона реальна.

Рішення: Якщо SERVFAIL приходить швидко від upstream, це не ваш фаєрвол, що відкидає відповіді. Якщо відповіді немає — переходьте до перевірки досяжності/втрат пакетів/anycast‑шляху.

Завдання 15: Протестуйте кілька anycast‑шляхів, запитуючи з іншого мережевого неймспейсу або хоста

cr0x@server:~$ dig @203.0.113.53 www.example.com A +stats
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21001
;; Query time: 19 msec
;; SERVER: 203.0.113.53#53(203.0.113.53) (UDP)

cr0x@server:~$ ssh cr0x@bastion 'dig @203.0.113.53 www.example.com A +stats'
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10442
;; Query time: 12 msec
;; SERVER: 203.0.113.53#53(203.0.113.53) (UDP)

Що це означає: Та сама IP‑адреса резольвера, інша точка — різний результат. Класична несумісність anycast‑POP або регіональна фільтрація.

Рішення: Ваша ескалація має включати «падає з ASN/локації A, працює з ASN/локації B» плюс часові відмітки.

Завдання 16: Підтвердіть, чи ваш резольвер форвардить (і кому)

cr0x@server:~$ sudo grep -R "forward-addr" /etc/unbound/unbound.conf /etc/unbound/unbound.conf.d 2>/dev/null
/etc/unbound/unbound.conf.d/forward.conf:forward-addr: 203.0.113.53
/etc/unbound/unbound.conf.d/forward.conf:forward-addr: 203.0.113.54

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

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

Як побудувати доказ для постачальника (без драм)

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

Як виглядає «доказ» для команди DNS‑операцій

• Точний IP резольвера, який повертає SERVFAIL (не «ваш DNS»).
• Точний запит: ім’я, тип, біти DO/CD, якщо важливо, і чи UDP чи TCP.
• Таймстампи з часовим поясом і частота («1 з 20 запитів падає» або «падає протягом 7 хвилин»).
• Порівняльні дані: той самий запит успішний проти іншого рекурсивного резольвера.
• Санність авторитетного шляху: dig +trace працює (або показує, де саме ламається).
• Вирізок захоплення пакетів, що показує код відповіді SERVFAIL або відсутність відповідей.
• Мережевий контекст: ваш діапазон джерела/ASN, регіон, чи є NAT.

Не надсилайте роман; надсилайте досьє

Добра ескалація — це лаконічно:

• Один абзац резюме: що не працює, вплив, коли почалося.
• Маркерний список IP‑адрес резольверів, що тестувалися, і результати.
• Максимум три виводи команд в першому повідомленні. Додайте решту як вкладення, якщо система квитків дозволяє.
• Один витяг tcpdump або pcap, якщо вони приймають.

Чого уникати

• «DNS впав.» Ні. Назвіть резольвер і запит.
• «Це випадково.» Це переривчасто. Надайте частоту відмов, часовий інтервал і чи корелює це з розміром EDNS0.
• «Ми перезавантажили щось.» Це скоріше запах проблеми, ніж доказ.

Жарт №2: Найшвидший спосіб змусити провайдера діяти — сказати «у мене є пакет‑захват», бо тепер це їхня проблема в HD‑якості.

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

Інцидент через хибне припущення: «SERVFAIL означає, що авторитетний не працює»

Середня SaaS‑компанія почала отримувати тривоги: зросла кількість помилок API, у кількох регіонах виникли проблеми зі входом. На‑oncall побачили SERVFAIL для імені провайдера і зробили те, що багато хто робить в стресі: припустили, що авторитетний DNS домену повинен бути зламаний.

Вони ескалували до вендора, відкрили тикет серйозності і почали готувати повідомлення клієнтам. Вендор відповів, що їхні авторитетні сервери здорові й надав свої логи запитів із нормальним трафіком. Oncall наполіг: «Та ж моя dig каже SERVFAIL.»

Спокійніший інженер поставив базове питання: «Яким резольвером ви запитували?» Виявилось, це був їхній власний форвардер, який форвардив на керовану рекурсивну службу, в комплекті з провайдером зв’язку. Запити до публічного резольвера працювали миттєво. dig +trace показав делегацію і авторитетні відповіді в порядку.

Справжній збій був у валідації DNSSEC в одному anycast‑POP керованого резольвера. Резольвер провайдера швидко повертав SERVFAIL для DNSSEC‑валидованих відповідей під час вікна rollover ключів. Форвардер компанії не мав диверсифікації; він форвардив виключно на цю керовану службу.

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

Оптимізація, що обернулась проти: «форвардити все, щоб зменшити латентність»

Фінансова компанія мала налаштований кластер Unbound для повної рекурсії, з кешуванням і валідацією DNSSEC. Хтось помітив, що хмарний провайдер пропонує «низьколатентні DNS‑резольвери» всередині VPC, і запропонував «просту оптимізацію»: змінити Unbound, щоб форвардити всі запити до хмарних резольверів.

У нормальний час це виглядало чудово. Медіана латентності впала. Використання CPU резольверів зменшилось. Усі похвалили зміни на зустрічі, де ніхто не запитав про режими відмов.

Через три тижні підмножина доменів почала переривчасто повертати SERVFAIL. Не всі домени, не всі запити. Команда гналася за привидами: повтори в додатку, пулл‑з’єднань, навіть TLS‑ручки. Це була DNS, але лише іноді і тільки через хмарні резольвери.

Корінь: флот резольверів хмари мав проблему з EDNS0‑фрагментацією на конкретному шляху до деяких авторитетних серверів. UDP‑відповіді певного розміру скидалися, а TCP‑fallback був непослідовний через політику пристрою безпеки. Повна рекурсія на їхніх Unbound раніше краще це обробляла, бо вони використали консервативні налаштування EDNS0 і передбачувану поведінку TCP.

«Оптимізація» створила новий blast radius: керовану залежність, яку вони не могли налаштувати. Вони відкотилися до повної рекурсії і зберегли хмарний резольвер як вторинний форвардер тільки для певних внутрішніх зон. Урок не в «ніколи не використовувати керований DNS». Урок — не віддавати критичний шлях, якщо ви не можете його спостерігати і не маєте fallback.

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

Ритейл‑платформа вже колись постраждала через DNS. Не катастрофічно — просто достатньо боляче, щоб коштувало грошей. Тому вони впровадили політику: у кожному регіоні має бути два рекурсивні резольвери, кожен здатний виконувати повну рекурсію, кожен з незалежним upstream‑підключенням. Клієнти мали два резольвери в resolv.conf, і їхня сервіс‑меш теж використовував диверсифікацію резольверів.

Вони також запускали постійні опитування: кожну хвилину, з кожного регіону, вони запитували невеликий набір критичних імен (свої auth‑ендпоїнти, платіжний шлюз і кілька зовнішніх залежностей) проти кожного резольвера, логуючи RCODE, латентність і чи використовувався TCP.

Одного дня один пул резольверів почав повертати SERVFAIL для домену платіжного шлюзу, але тільки в одному регіоні. Оскільки у них була телеметрія по‑резольверно, проблема стала очевидною за хвилини: резольвер A у цьому регіоні поганий; резольвер B — в порядку. Клієнти автоматично перемкнулися, тож вплив на клієнтів був мінімальний.

Коли вони відкрили тикет до провайдера зв’язку, вони не казали «DNS переривчастий». Вони сказали: «Резольвер IP X повертає SERVFAIL для імені Y, починаючи о T; резольвер IP Z — ні. Ось щохвилинні підрахунки RCODE і вирізок tcpdump.» Провайдер того ж дня виправив зламаний вузол в POP.

Нічого героїчного не сталося. Саме тому це спрацювало.

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

1) Симптом: SERVFAIL лише на резольвері вашого провайдера; публічні резольвери працюють

Корінь: Рекурсивний збій провайдера, будькаст‑POP неконсистентний або політика провайдера (фільтрація/RPZ).

Виправлення: Запитуйте конкретні IP резольверів напряму, збирайте tcpdump‑докази і тимчасово переключіть/додайте резольвери. Ескалюйте з IP резольвера + часовими відмітками.

2) Симптом: SERVFAIL зникає при використанні +cd

Корінь: Помилка валідації DNSSEC (пошкоджений DS‑ланцюг, прострочені підписи, неправильний trust anchor або зсув годинника резольвера).

Виправлення: Перевірте синхронізацію часу; запустіть dig +trace і перегляньте ланцюг DS/DNSKEY; якщо upstream‑валидатор неправильний — ескалюйте з «валідація не проходить на резольвері IP X; працює в інших місцях».

3) Симптом: Малі відповіді працюють; великі — SERVFAIL/таймаут

Корінь: EDNS0‑фрагментація/PMTUD‑проблеми; TCP/53 заблоковано; middlebox‑и псують фрагменти.

Виправлення: Тестуйте з +bufsize=1232 і +tcp. Якщо це виправляє — налаштуйте EDNS0‑розмір резольвера, забезпечте доступ TCP/53 і ескалюйте з пакетними захватами до мережевої команди/провайдера.

4) Симптом: Переривчастий SERVFAIL відрізняється за регіонами

Корінь: Anycast‑маршрутизація до різних вузлів резольвера; один POP хворий; неконсистентний кеш/стан валідації.

Виправлення: Тестуйте з кількох точок; включіть IP джерела/регіон у докази; попросіть провайдера злити/полагодити POP.

5) Симптом: SERVFAIL для домену, який ви щойно оновили

Корінь: Неправильна делегація/DS під час rollover DNSSEC; застаріле негативне кешування; неконсистентна авторитетна реплікація.

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

6) Симптом: Деякі клієнти падають; інші — працюють в тій самій мережі

Корінь: Різні налаштовані резольвери (DHCP), split DNS, VPN, який нав’язує резольвери, або локальні stub/кеші.

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

7) Симптом: SERVFAIL, але в логах вашого резольвера порожньо

Корінь: Ви фактично не запитуєте той резольвер, про який думаєте; або запити перехоплює локальний stub / sidecar / NAT‑пристрій.

Виправлення: Використовуйте dig @IP явно; захопіть пакети на клієнті; підтвердіть, що трафік доходить до очікуваної IP‑адреси резольвера.

8) Симптом: SERVFAIL після змін для «удосконалення безпеки»

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

Виправлення: Увімкніть TCP/53 і фрагменти за потреби; налаштуйте EDNS0‑буфер; перевірте DNSSEC контрольовано перед масовим розгортанням змін.

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

Покроково: від першої тривоги до ескалації провайдеру

1. Підтвердіть масштаб впливу: це одне ім’я, один резольвер, один регіон чи глобально?
2. Визначте активний резольвер на ураженому хості (resolvectl status).
3. Відтворіть з явними запитами: dig @resolver name type +stats.
4. Порівняйте з другим резольвером (публічним або альтернативним внутрішнім). Зафіксуйте різниці в RCODE і латентності.
5. Запустіть dig +trace, щоб довести, що авторитетний ланцюг працює (або вказати, де ламається).
6. Перевірте DNSSEC: запустіть з і без +cd; перевірте логи валідувального резольвера; підтвердіть синхронізацію часу.
7. Перевірте транспорт: +tcp, +bufsize=1232 і підтвердіть досяжність TCP/53.
8. Захопіть пакети, що показують SERVFAIL від upstream або відсутні відповіді.
9. Документуйте «матрицю» доказів: IP резольверів × точки вимірювання × результати.
10. Мітігуйте: переключіть на альтернативні резольвери, увімкніть fallback або тимчасово відключіть DNSSEC тільки з усвідомленням ризику та дозволом.
11. Ескалюйте: надішліть коротке резюме плюс ключові докази, попросіть перевірити POP/вузол, якщо підозрюється anycast.
12. Фоллов‑ап: продовжуйте опитування і додайте постійний моніторинг; напишіть постмортем з пунктом «як ми це виявимо за 2 хв наступного разу».

Швидкі заходи пом’якшення (коли продакшен кровоточить)

• Переключіть клієнти на принаймні два різні резольвери (різних провайдерів, якщо можливо).
• На форвардерах додайте кілька upstream і перевіряйте їх здоров’я; надавайте перевагу тим, що мають незалежні anycast‑мережі.
• Якщо підозрюєте фрагментацію: зменшіть EDNS0 UDP‑розмір і переконайтеся, що TCP/53 дозволено.
• Якщо підозрюєте DNSSEC: спочатку перевірте час; не вимикайте валідацію глобально як перший крок.
• Зменшіть залежність від одного рекурсивного резольвера: це єдина точка відмови, хай і в маскараді SLA.

Чекліст пакета доказів (що прикріпити до тикета)

• IP‑адреси резольверів, які тестувалися, і їхні RCODEи (SERVFAIL vs NOERROR) для того самого запиту.
• Таймстампи та часовий пояс.
• Вивід dig +trace, що показує авторитетні відповіді.
• Вивід dig, який показує різницю з +cd, якщо підозрюється DNSSEC.
• Вирізок tcpdump або pcap з SERVFAIL від upstream резольвера.
• Ваше джерельне IP/публічний egress і регіон (особливо якщо anycast).

FAQ

1) Чому мій резольвер повертає SERVFAIL замість таймауту?

Тому що щось upstream відповіло SERVFAIL або ваш резольвер натрапив на помилку валідації/політики. Швидкий SERVFAIL часто — навмисне рішення, а не втрата пакета.

2) Якщо dig +trace працює, чи все ще може бути винен провайдер?

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

3) Чи означає SERVFAIL завжди проблеми з DNSSEC?

Ні. DNSSEC — поширена причина, але також можливі upstream‑аутейджі, лімітування, таймаути до авторитетних серверів, зламаний TCP‑fallback та втручання middlebox.

4) Що означає, коли +cd робить запит успішним?

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

5) Чи варто просто відключити валідацію DNSSEC, щоб зупинити інцидент?

Тільки як тимчасовий захід з явним прийняттям ризику. Вимкнення валідації міняє цілісність на доступність. Іноді це правильне рішення бізнес‑пріоритету; часто — панічний крок, що стає постійним.

6) Чому лише деякі регіони бачать SERVFAIL, якщо резольвери anycast?

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

7) Як довести, що це не наш фаєрвол/NAT?

Якщо ви маєте захоплення пакетів, що показує upstream SERVFAIL‑відповідь у вашому інтерфейсі — то це не ваш фаєрвол, що відкидає відповіді. Якщо ви бачите лише вихідні запити без відповідей — потрібні додаткові тести: TCP vs UDP, розміри EDNS, перевірки з іншого egress.

8) Чому зменшення +bufsize до 1232 допомагає?

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

9) Чи може «безпечний DNS» провайдера спричинити SERVFAIL?

Так. Деякі реалізації фільтрації повертають NXDOMAIN, деякі — SERVFAIL, а деякі — «дружню» переадресацію. Якщо публічні резольвери успішні, а резольвери провайдера послідовно падають — підозрюйте політику.

10) Що просити у провайдера?

Попросіть їх перевірити конкретний IP резольвера/POP на рекурсію або проблеми валідації DNSSEC, перевірити фрагментацію/TCP‑fallback, і підтвердити, чи застосовується фільтрація/RPZ.

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

SERVFAIL — це не діагноз. Це вимога до кращих запитань. Найшвидший шлях до ясності — контрольоване порівняння: ваш резольвер проти іншого резольвера, рекурсія проти trace, валідація увімкнена проти вимкненої, UDP проти TCP. Потім зберіть докази.

Кроки, які ви можете зробити сьогодні:

• Запишіть IP‑адреси резольверів, які фактично використовує ваш флот. Додайте їх у моніторинг.
• Додайте невеликий набір постійних DNS‑опитувань, що фіксують RCODE, латентність і використання TCP для кожного резольвера і регіону.
• Переконайтеся, що TCP/53 дозволено там, де потрібно, і налаштуйте EDNS0‑буфер консервативно, якщо ви оперуєте резольверами.
• Проєктуйте систему з диверсифікацією резольверів. Один upstream — це одна точка відмови, навіть якщо він anycast і має гарний SLA.
• Коли постачальник винен, ескалюйте з досьє: IP резольвера, точний запит, таймстампи, trace‑доказ і пакети. Ви отримаєте дію, а не поезію.