DNS: Сильні прийоми dig/drill — команди, що відповідають на 90% DNS-загадок

Мислення про DNS: припиніть гадати, почніть визначати крок

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

Більшість DNS-загадок зводяться до одного з цього:

• Ви запитали не те місце. Різні резолвери — різні види (split-horizon), різний вміст кешу.
• Ви запитали правильне місце, але не ту назву/тип. A/AAAA vs CNAME/ALIAS, відсутня кінцева крапка у файлах зони, пошукові домени в резолвері.
• Ланцюг зламано. Невідповідність делегування, неправильний glue, lame делегування, реєстратор не оновлено, невідповідність DS.
• Це закешовано. TTL, негативне кешування, застарілі відповіді, передзавантаження резолверів, кеші клієнта.
• Технічно вірно, але операційно невірно. Ви вказали на балансувальник навантаження, котрий недоступний із тієї мережі, або повернули AAAA для сервісу, який фактично не слухає на IPv6.
• Це політика. DNSSEC валідація, фільтрація, переписування NXDOMAIN, корпоративні проксі або внутрішні резолвери, що роблять «корисні» речі.

Ваше завдання під час інциденту — відповісти з доказами: хто відповів, який шлях пройшов запит і що зміниться, якщо ми виправимо зараз (TTL/кеші). dig і drill — ваш кишеньковий ніж і лампа.

Цитата, яку варто тримати в голові, бо відлагодження DNS — це проблема надійності, замаскована під запит:

Переказ ідеї (John Allspaw): «Інциденти не вирішують звинуваченням людей; їх вирішують поліпшенням систем і розумінням того, як робота фактично відбувається.»

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

Цікаві факти про DNS (корисні під час аварій)

1. DNS старший за сучасний інтернет у вашому розумінні. Він замінив централізовану модель HOSTS.TXT на початку 1980-х, коли «всі редагують один файл» перестало масштабуватися.
2. «Рекурсивні» та «авторитарні» — різні ролі. Авторитарні сервери публікують істину для зон; рекурсивні резолвери отримують істину і кешують її для клієнтів.
3. Негативне кешування існує. NXDOMAIN (або NODATA) може кешуватися, кероване полями SOA (мінимальний/негативний TTL) — тому запис, що був доданий, може «не існувати» ще деякий час.
4. Glue-записи потрібні через реальну проблему курка/яйце. Якщо імʼя nameserver-а знаходиться в зоні, яку він обслуговує, батьківська зона повинна надати glue A/AAAA для завантаження резолюції.
5. Флентення CNAME — це операційний обхід. Специфікація забороняє CNAME в апексі зони, але люди хочуть поведінку апекса як CDN — звідси ALIAS/ANAME або флеттінг у провайдера.
6. EDNS0 додали, бо повідомлення DNS стали більші. Класичний DNS по UDP мав обмеження розміру; EDNS0 розширює це, щоб сучасні записи (особливо DNSSEC) вміщувалися без миттєвого fallback на TCP.
7. Помилки DNSSEC виглядають як «випадковий SERVFAIL». Багато резолверів приховують подробиці, якщо ви не задаєте правильні питання; помилки валідації часто спочатку невідрізнені від відмов.
8. Резолвери не зобов’язані поводитися однаково. Алгоритми кешування, передзавантаження, «serve stale», агресивне кешування NSEC і стратегії таймаутів різняться — тож «працює на 8.8.8.8» — доказ, а не вирок.

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

Перше: підтвердьте, що робить клієнт

• Який резолвер використовує клієнт? Корпоративний VPN, локальний роутер, systemd-resolved stub, браузерний DoH?
• Яка назва і тип? A проти AAAA, розширення пошукового суфіксу, відсутня кінцева крапка, регістр не має значення (DNS нечутливий до регістру в мітках).
• Що саме за симптом? NXDOMAIN, SERVFAIL, таймаут, неправильний IP, переривчасто?

Друге: порівняйте рекурсивне та авторитарне «істини»

• Запитайте відомий публічний рекурсивний резолвер (або два) і порівняйте: чи погоджуються вони?
• Запитайте авторитарні сервери безпосередньо. Якщо авторитарний відповідає правильно, а рекурсивний — ні, ви в зоні кешування/пропагації/валідації.
• Протрасуйте делегування. Якщо ланцюг обривається на батьківському рівні, виправляйте реєстратор/NS/glue/DS — не файл зони.

Третє: вирішіть, чи ви боретесь із кешуванням, делегуванням, доступністю чи політикою

• Кешування: TTL, негативний TTL, кеші клієнтів, serve-stale резолверів, застарілі NS у кешах.
• Делегування: невідповідність NS у батька і дитини, неправильний glue, lame делегування.
• Доступність: UDP/53 блокується, TCP/53 блокується (важливо для DNSSEC/великих відповідей), проблеми з anycast шляхом.
• Політика: DNSSEC валідація, RPZ-фільтрація, переписування NXDOMAIN, розбіжності у views (split-horizon).

Якщо пройти ці три кроки, ви швидко отримаєте правильне формулювання проблеми: «Авторитарний відповідає правильно, але резолвер X кешує NXDOMAIN на 10 хв через SOA min TTL,» — краще, ніж «DNS якийсь дивний».

Сильні прийоми dig/drill: реальні завдання, команди, результати, рішення

Нижче — практичні завдання, які ви виконуватимете під час реальних інцидентів. Кожне містить: команду, що означає її вивід, і яке рішення прийняти далі. Користуйтесь dig, якщо він є; drill — коли потрібне вбудоване трасування та трохи інша перспектива. Я використовую обидва, бо продакшн-системи не переймаються вашими вподобаннями.

Завдання 1: Визначити, кого ви фактично запитуєте (перевірка «хто відповів»)

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

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com.                   IN      A

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

;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Dec 31 10:12:44 UTC 2025
;; MSG SIZE  rcvd: 56

Значення: Рядок SERVER показує, хто відповів. Тут це 127.0.0.53, systemd-resolved stub, а не корпоративний резолвер чи публічний резолвер.

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

Завдання 2: Запитати конкретний рекурсивний резолвер для порівняння поведінки

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

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50289
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
example.com.            300     IN      A       93.184.216.34

Значення: Ви запитали Cloudflare-resolver безпосередньо. Якщо відповідь відрізняється від локальної, ймовірно маєте справу зі split-horizon, фільтрацією або різним станом кешу.

Рішення: Порівняйте 2–3 резолвери (ваш корпоративний, один публічний). Узгодженість між ними свідчить про послідовну авторитарну правду; розбіжності — про view/policy/caching.

Завдання 3: Перевірити TTL, щоб спрогнозувати «коли користувачі побачать виправлення»

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

api.corp.example.       17      IN      A       203.0.113.10

Значення: TTL становить 17 секунд. Це залишковий час життя в кеші саме цього резолвера зараз, а не обов’язково налаштований TTL зони.

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

Завдання 4: Запитати авторитарні сервери без кешування, щоб обійти рекурсивні кеші

cr0x@server:~$ dig ns1.dns-provider.example api.corp.example A +norecurse +noall +answer +comments

api.corp.example.       300     IN      A       203.0.113.10

Значення: +norecurse наказує серверу не виконувати рекурсію. Якщо він все одно відповідає, ви звертаєтесь до авторитарного сервера для цієї зони (або до резолвера, що ігнорує вас, але авторитетні сервери зазвичай так не роблять).

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

Завдання 5: Прослідкувати шлях делегування від кореня до кінця (знайти, де ланцюг обривається)

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

; <<>> DiG 9.18.24 <<>> +trace www.example.org A
;; Received 811 bytes from 127.0.0.53#53(127.0.0.53) in 1 ms

org.                    86400   IN      NS      a0.org.afilias-nst.info.
org.                    86400   IN      NS      a2.org.afilias-nst.info.
...
example.org.            172800  IN      NS      ns1.dns-provider.example.
example.org.            172800  IN      NS      ns2.dns-provider.example.
...
www.example.org.        300     IN      A       198.51.100.44

Значення: +trace проходить root → TLD → авторитарний. Якщо воно падає на кроці TLD, делегування в реєстраторі/батьку зламано. Якщо воно падає на кроці авторитарних — ваші авторитарні сервери не відповідають правильно.

Рішення: Виправляйте шар, на якому зупиняється трасування. Не чіпайте код застосунку. DNS не переймається вашим пайплайном деплойменту.

Завдання 6: Використати drill для трасування й помітнішого відображення DS/DNSSEC

cr0x@server:~$ drill -TD www.example.org

;; Number of trusted keys: 1
;; Chasing: www.example.org. A
www.example.org.        300     IN      A       198.51.100.44
;; Chase successful

Значення: drill -T трасує; -D дає деталі, пов’язані з DNSSEC. «Chase successful» — швидка перевірка, що ланцюг у принципі резольвиться.

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

Завдання 7: Діагностувати SERVFAIL, перевіривши валідацію DNSSEC явно

cr0x@server:~$ dig @1.1.1.1 broken-dnssec.example A +dnssec +multi

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24670
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Значення: Деякі резолвери повертають SERVFAIL, коли DNSSEC-валідація провалюється (або коли upstream-запити не вдаються). +dnssec просить DNSSEC-записи; це не примушує валідацію, але допомагає побачити, чи є RRSIG при запиті авторитарних серверів.

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

Завдання 8: Перевірити наявність авторитарних DNSSEC-матеріалів (DNSKEY, RRSIG)

cr0x@server:~$ dig ns1.dns-provider.example broken-dnssec.example DNSKEY +norecurse +dnssec +noall +answer

broken-dnssec.example.  3600    IN      DNSKEY  257 3 13 ( ... )
broken-dnssec.example.  3600    IN      RRSIG   DNSKEY 13 2 3600 ( ... )

Значення: Ви перевіряєте, чи зона публікує DNSKEY і чи підписана вона (RRSIG). Якщо DNSKEY є, але резолвери повертають SERVFAIL, DS у батька може не відповідати, або підписи прострочені.

Рішення: Якщо DNSKEY/RRSIG відсутні або неправильні — виправляйте підписання зони. Якщо вони присутні, перевірте DS у батьківській зоні (Завдання 9).

Завдання 9: Перевірити DS-запис у батьку (чи ціла ланка довіри?)

cr0x@server:~$ dig +trace broken-dnssec.example DS

; <<>> DiG 9.18.24 <<>> +trace broken-dnssec.example DS
...
example.                86400   IN      NS      a.iana-servers.net.
...
broken-dnssec.example.  86400   IN      DS      12345 13 2 ( ... )

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

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

Завдання 10: Виявити ланцюги CNAME та місце їх обриву

cr0x@server:~$ dig cdn.example.net A +noall +answer

cdn.example.net.        60      IN      CNAME   cdn.vendor.example.
cdn.vendor.example.     60      IN      CNAME   edge123.vendor.example.
edge123.vendor.example. 20      IN      A       192.0.2.80

Значення: Ви маєте не проблему з A-записом, а ланцюг. Перерив у будь-якому місці повертає NXDOMAIN або SERVFAIL залежно від обставин.

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

Завдання 11: Розрізнити NXDOMAIN та NODATA (та сама назва, різні відмови)

cr0x@server:~$ dig nonexistent.example.com A +noall +comments

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10832
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

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

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40420
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Значення: NXDOMAIN означає, що імені не існує. NOERROR з нульовою секцією ANSWER часто означає, що ім’я існує, але не для цього типу запису (NODATA). Вони кешуються по-різному і вказують на різні конфігураційні проблеми.

Рішення: Якщо NXDOMAIN — перевіряйте вміст зони і делегування. Якщо NODATA — ймовірно ви забули опублікувати потрібний тип запису (наприклад, TXT для верифікації) або опублікували його в іншому view.

Завдання 12: Перевірити негативний TTL через SOA (чому NXDOMAIN зберігається)

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

example.com.            300     IN      SOA     ns1.dns-provider.example. hostmaster.example.com. 2025123101 7200 900 1209600 600

Значення: Останнє поле в SOA (тут 600) часто використовується як негативний TTL на практиці. Якщо ви випадково видалили запис і повернули його, резолвери можуть тримати «не існує» протягом цього часу.

Рішення: Якщо негативний TTL високий — плануйте відкладене відновлення після виправлення NXDOMAIN. У критичних випадках можна тимчасово відповісти іншим ім’ям (новою міткою), яке не кешується негативно.

Завдання 13: Перевірити делегування: порівняйте NS у батька і в дитини

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

example.org.            172800  IN      NS      ns1.dns-provider.example.
example.org.            172800  IN      NS      ns2.dns-provider.example.

cr0x@server:~$ dig @ns1.dns-provider.example example.org NS +norecurse +noall +answer

example.org.            3600    IN      NS      ns1.dns-provider.example.
example.org.            3600    IN      NS      ns2.dns-provider.example.
example.org.            3600    IN      NS      ns3.dns-provider.example.

Значення: Батько каже ns1+ns2; дитина каже ns1+ns2+ns3. Ця невідповідність не завжди фатальна, але це класичне джерело непослідовної поведінки та «деякі резолвери питають не той сервер».

Рішення: Узгодьте набори NS у батька і дитини. Під час інцидентів видаліть мертві або неправильні NS з обох боків; lame сервери збільшують таймаути і можуть спричиняти шторми повторних запитів.

Завдання 14: Виявити lame делегування (NS в списку, але не авторитарний)

cr0x@server:~$ dig @ns3.dns-provider.example example.org SOA +norecurse +noall +comments

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 61120
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

Значення: Якщо NS перерахований, але відмовляє або повертає SERVFAIL/REFUSED на авторитарні запити, деякі резолвери марно втрачають час на нього. Це — «lame делегування» на практиці.

Рішення: Видаліть цей NS з делегування (і/або виправте його конфігурацію). Таймаути тут проявляють себе як повільні сторінки і переривчасті відмови.

Завдання 15: Перевірити, чи працює TCP-fallback (для великих відповідей, DNSSEC, усічених UDP)

cr0x@server:~$ dig @8.8.8.8 dnssec-large.example TXT +dnssec +noall +comments

;; Truncated, retrying in TCP mode.

cr0x@server:~$ dig @8.8.8.8 dnssec-large.example TXT +dnssec +tcp +noall +answer

dnssec-large.example.   300     IN      TXT     "v=some-long-value..."

Значення: Якщо UDP усічено, резолвери повторюють запит по TCP. Якщо TCP/53 блокується десь (фаєрвол, security group, корпоративні проксі), ви отримаєте містичні відмови, що корелюють з розміром відповіді.

Рішення: Переконайтеся, що TCP/53 дозволено між резолверами і авторитарними серверами (і від клієнтів до резолверів, якщо потрібно). Не «оптимізуйте безпеку», блокуючи TCP/53 без розуміння DNSSEC і сучасних розмірів відповідей.

Завдання 16: Перевірити split-horizon DNS, опитуючи внутрішні й зовнішні резолвери

cr0x@server:~$ dig @10.0.0.53 app.internal.example A +noall +answer

app.internal.example.   30      IN      A       10.10.20.15

cr0x@server:~$ dig @1.1.1.1 app.internal.example A +noall +comments

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5904
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Значення: Внутрішній резолвер відповідає RFC1918-адресою; публічний резолвер каже NXDOMAIN. Це навмисний split-horizon — поки не стане проблемою. Якщо клієнти по VPN використовують публічний DoH, вони не побачать внутрішні записи.

Рішення: Визначте політику: або примусово використовувати внутрішній резолвер на керованих пристроях (і вимкнути незадовільний DoH), або публікувати публічні еквіваленти. Не ілюструйте, що split-horizon невидимий; він впливає на поведінку додатків.

Завдання 17: Перевірити зворотні записи (PTR) для пошти, логування і «чому нас блокують»

cr0x@server:~$ dig -x 203.0.113.10 +noall +answer

10.113.0.203.in-addr.arpa. 3600 IN PTR mailout.example.com.

Значення: Зворотний DNS існує і вказує на хостнейм. Багато систем (особливо поштові) використовують його як слабкий сигнал ідентичності.

Рішення: Якщо PTR відсутній або неправильний — узгоджуйте це з власником IP (зазвичай ваш провайдер хмари). Також забезпечте forward-confirmed reverse DNS там, де це важливо (PTR вказує на ім’я, а ім’я резольвиться назад на той самий IP).

Завдання 18: Виміряти латентність і швидко виявити таймаути

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

; <<>> DiG 9.18.24 <<>> @9.9.9.9 www.example.com A +stats +tries=1 +time=2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31869
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
www.example.com.        60      IN      A       198.51.100.44
;; Query time: 187 msec
;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP)
;; WHEN: Wed Dec 31 10:20:12 UTC 2025
;; MSG SIZE  rcvd: 59

Значення: Ви отримуєте час запиту в мілісекундах. Стрибок тут може бути через шлях у мережі, перевантаження резолвера, upstream-таймаути через lame делегування або фільтрацію пакетів.

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

Жарт №2: Якщо ви займаєтеся DNS о 3-й ночі, памʼятайте: записи незмінні, поки ви не перестанете друкувати.

Три корпоративні міні-історії з DNS-трішків

Інцидент №1: Відмова через хибне припущення

Компанія: середній SaaS, глобальні клієнти, два регіони хмар. Новий кінцевий точок сервісу був запущений за CDN. Команда додала CNAME і пішла далі. Всі тестували з ноутів. Здавалося, все працює.

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

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

Діагностика полягала в трасуванні з мережі, що падала. dig +trace показав, що батько рекламує набір NS, який включав nameserver, що більше не обслуговував зону. Запит до того сервера напряму повертав REFUSED. «У мене працює» команда мала резолвери, яким не пощастило потрапити на lame NS.

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

Інцидент №2: Оптимізація, що обернулась проблемою

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

Потім вони додали залежність від зовнішнього провайдера аутентифікації з довгим CNAME-ланцюгом і DNSSEC. У нормальний день — нічого. У поганий — рекурсивні резолвери компанії були перегріті. Низький TTL означав постійні промахи кешу. Резолвери змушені були постійно проходити ланцюги, підвантажувати DNSKEY/RRSIG і іноді переходити на TCP, коли відповіді були великі.

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

Виправлення: перестати трактувати TTL як ручку продуктивності, яку можна різко зменшувати без наслідків. Вони підвищили TTL для стабільних записів, залишили низький TTL лише для імен з контролем фейловеру, і додали потужності резолверам. Також перестали блокувати TCP/53 на вихід — бо UDP не достатній. Це не безкоштовно.

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

Інцидент №3: Нудна але коректна практика, що врятувала день

Ще одна організація, ще один день. Вони тримали власний авторитарний DNS з керованим провайдером і мали рутину, що виглядала як паперова робота: перед будь-якою зміною вони збирали «before» виводи для SOA, NS і змінених записів з обох авторитарних серверів і з двох публічних резолверів. Вони зберігали ці снипети в тікеті на зміну.

Під час п’ятничної зміни інженер додав AAAA-запис, що вказував на нову IPv6-адресу для сервісу, яка фактично не була доступна з усіх мереж. Сервіс був dual-stack в одному регіоні і тільки v4 в іншому. Користувачі в мережах, що віддають перевагу IPv6, отримували таймаути. Користувачі тільки з IPv4 були в порядку. Моніторинг, переважно IPv4, залишався зеленим.

Оскільки вони мали «before» знімки, вони швидко довели, що єдина зміна в DNS — це AAAA. Потім відтворили проблему, запитуючи A і AAAA окремо і тестуючи підключення. DNS був «правильний», але деплоймент — ні. Найшвидше помʼякшення було видалити AAAA (або правильно налаштувати маршрути IPv6), а не керувати резолверами.

Нудна практика — знімки dig перед змінами і перевірка A/AAAA окремо — перетворила міжкомандне звинувачення на 30-хвилинне виправлення. Звіт по інциденту був короткий. Ось цього і прагнуть.

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

• Симптом: «Деякі користувачі отримують NXDOMAIN для запису, який зараз існує.»

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

  Виправлення: Перевірте SOA (негативний TTL), зачекайте, або тимчасово змініть мітку; тримайте негативний TTL розумним для зон, що часто змінюються.

• Симптом: «Працює на публічному DNS, падає через корпоративний VPN.»

  Корінь: Split-horizon views, RPZ-фільтрація, або внутрішній резолвер повертає приватні IP, недоступні з мережі клієнта.

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

• Симптом: «SERVFAIL на валідаційних резолверах, NOERROR на невалідаційних.»

  Корінь: Невідповідність DS/DNSKEY, прострочені підписи, відсутній DNSKEY на деяких авторитарних вузлах.

  Виправлення: Перевірте DS через trace; виправте підписання або DS; забезпечте, щоб всі авторитарні вузли подавали узгоджений DNSSEC-матеріал.

• Симптом: «Переривчастий повільний DNS; іноді 2–5 секунд.»

  Корінь: Lame делегування або мертвий NS у наборах батька/дитини, що викликає повтори; резолвери перебирають список NS.

  Виправлення: Порівняйте NS у батька і дитини; опитайте кожен NS за SOA з +norecurse; видаліть мертві NS; знизьте TTL NS під час переходу.

• Симптом: «A-запис виглядає правильно, але клієнти все ще бачать старий IP.»

  Корінь: TTL все ще високий у кешах; локальні stub-кеші; браузери з DoH; кешування на рівні застосунку.

  Виправлення: Перевірте TTL у того резолвера, який використовують постраждалі; запитайте авторитарні сервери; очистьте відповідний кеш (systemd-resolved, nscd, unbound) якщо контролюєте його; інакше чекайте або робіть overlap-роллаут.

• Симптом: «Тільки великі TXT записи не проходять; малі запити в порядку.»

  Корінь: Проблеми фрагментації UDP, EDNS шляхові MTU проблеми або блокування TCP/53 для fallback.

  Виправлення: Тестуйте dig +tcp; дозволяйте TCP/53; розгляньте зменшення EDNS UDP розміру на резолверах; уникайте гігантських записів, коли це можливо.

• Симптом: «Перехід на CDN не пройшов; частина трафіку йде на origin.»

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

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

• Симптом: «Постачальник пошти каже, що наш зворотний DNS неправильний.»

  Корінь: Відсутній PTR, PTR вказує на ім’я, що не резольвиться назад, або ви змінили вихідний IP без оновлення rDNS.

  Виправлення: Перевірте за допомогою dig -x і прямий lookup; оновіть PTR через власника IP; тримайте rDNS узгодженим із ідентичністю відправника.

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

Чекліст: триаж «DNS зламаний» за 10 хвилин

1. Запишіть точну назву і тип. Приклад: api.example.com AAAA, а не «DNS API».
2. Опитайте налаштований резолвер клієнта. Підтвердіть рядок SERVER і статус (NOERROR/NXDOMAIN/SERVFAIL/таймаут).
3. Опитайте два відомі рекурсивні резолвери. Якщо вони не погоджуються — маєте розбіжності view/policy/caching.
4. Опитайте авторитарні сервери напряму. Якщо авторитарні правильні, а рекурсивні ні — припиніть сліпо змінювати зони.
5. Запустіть +trace для проблемної назви. Зафіксуйте, на якому кроці відбувається зупинка.
6. Перевірте TTL (позитивний і негативний). Вирішіть, чи можна чекати, чи потрібен обхід.
7. Перевірте A і AAAA окремо. Подвійний стек дає часто болючі сюрпризи.
8. Якщо SERVFAIL — підозрюйте DNSSEC раніше. Перевіряйте ланцюг DS/DNSKEY замість сперечань із командами застосунку.
9. Якщо повільно/переривчасто — підозрюйте делегування/здоровʼя NS. Тестуйте кожен NS за SOA-запитами.
10. Збирайте докази. Вставляйте виводи dig у документ інциденту. DNS-спори швидко закінчуються, коли показуєш ланцюг.

Чекліст: планована зміна DNS (щоб не створити наступного тижня інцидент)

1. Визначте модель пропагації. Зниження TTL за 24–48 годин до cutover для високонавантажених імен — нормальна практика. Робіть це свідомо.
2. Зніміть «before» снапшоти: SOA, NS, цільові записи і будь-які CNAME-ланцюги з авторитарних і як мінімум одного рекурсивного резолвера.
3. Робіть по одній зміні за раз. Зміни NS + DNSSEC + service cutover разом — гарантований шлях до вихідних вихідних.
4. Перевіряйте з кількох мереж/резолверів. Особливо якщо у вас split-horizon або корпоративні клієнти.
5. Майте простий rollback. Знайте, до чого саме повернути записи, і усвідомлюйте існування кешів.
6. Після зміни перевірте консистентність делегування. NS у батька і дитини повинні збігатися, і всі NS мають відповідати авторитарно.

Очищення кешу (тільки коли ви контролюєте вузол)

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

cr0x@server:~$ sudo resolvectl flush-caches

Значення: На системах із systemd-resolved це очищає локальний кеш. Це не виправить кеші upstream у резолверів, якими ви не керуєте.

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

Питання та відповіді

1) У чому практична різниця між dig і drill?

dig (інструменти BIND) — повсюдний і зручний для скриптів. drill (із ldns) має зручне трасування і можливості DNSSEC chase. У інцидентах використовуйте те, що встановлено першим — і тримайте інший під рукою для другої думки.

2) Коли слід використовувати +trace?

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

3) Чому один резолвер повертає IP, а інший — NXDOMAIN?

Поширені причини: split-horizon views, RPZ/фільтрація, застарілі кеші (включно з негативними), або ви питаєте різні імена через пошукові домени. Опитуйте обидва резолвери напряму та порівнюйте status, ANSWER і AUTHORITY.

4) Що насправді означає SERVFAIL?

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

5) Чому я бачу правильні записи на авторитарному сервері, але клієнти все ще бачать стару відповідь?

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

6) Як довести, що DNSSEC — проблема без спеціалізованих інструментів?

Перевірте, чи валідаційні резолвери повертають SERVFAIL, а невалідаційні або прямі запити до авторитарних повертають дані. Потім перегляньте DNSKEY/RRSIG на авторитарних серверах і DS у батьку через dig +trace DS. Цього зазвичай достатньо, щоб показати проблему.

7) Чи завжди потрібно публікувати AAAA, якщо сервіс доступний через IPv6 десь?

Ні. Публікуйте AAAA, коли сервіс надійно доступний по IPv6 для користувачів, які його отримуватимуть. Часткові IPv6-розгортання створюють повільні відмови, що виглядають як «додаток ненадійний», бо клієнти часто спочатку пробують v6.

8) Що таке «lame делегування» практично?

NS, перерахований для вашої зони, який фактично її не обслуговує авторитарно (або відмовляє/повертає SERVFAIL). Резолвери марно витрачають час на нього. Ви отримуєте переривчасту повільну роботу, повтори і іноді відмови. Виправляйте, видаляючи або лагодячи сервер і узгоджуючи NS у батька і дитини.

9) Чому TXT-верифікаційний запис видно мені, але не провайдеру?

Або ви опитуєте різні резолвери з різними кешами, або опублікували в неправильній зоні/view, або створили NODATA (ім’я існує, але без TXT) замість фактичного запису. Запитайте провайдера, який резолвер вони використовують, і опитайте цей резолвер напряму.

10) Чи добре очищати кеші як реакція на інцидент?

Лише якщо ви контролюєте цей кеш і робите це, щоб перевірити гіпотезу. Ви не можете очистити кеші всіх світових резолверів. Справжнє вміння — розуміти TTL і планувати безпечні cutover-и з перекриттям.

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

1. Виробіть звичку «DNS-доказів». Під час інцидентів вставляйте в документ інциденту виводи dig/drill, що показують SERVER, статус, TTL і авторитарні відповіді. Це скорочує збори.
2. Стандартизуйте порівняння резолверів. Виберіть два публічні резолвери і ваш корпоративний, і тримайте короткий набір команд для швидкого порівняння.
3. Знайте своє делегування. Для критичних зон періодично перевіряйте, чи NS батька збігаються з NS дитини і чи кожен NS відповідає авторитарно.
4. Перегляньте стратегію TTL. Низькі TTL лише там, де вам реально потрібне швидке керування; здорові TTL скрізь інде зменшують навантаження на залежності.
5. Зробіть TCP/53 обов’язковим для DNS-інфраструктури. Сучасний DNS (особливо з DNSSEC) потребує TCP при усічених UDP-відповідях.
6. Практикуйте контрольований rollback DNSSEC. Не під час інциденту. Знайте, як видалити DS і як безпечно повторно ввімкнути.

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