Сети и протоколы
DNS: чтение dig и зонных файлов
Суть Читайте реальный вывод dig, зонный файл и конфиг резолвера, предсказывайте поведение DNS и выбирайте диагноз или фикс, к которому сеньор потянется первым.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеDNS-инциденты диагностируются в выводе dig и зонных файлах, а не на слайдах. Прочитайте каждый артефакт, предскажите, о чём он говорит, и выберите решение, которое сеньор примет первым.
Цель
Отработайте цикл, который вы запускаете в каждом DNS-инциденте: прочитать trace или зонный файл, найти порванное звено и потянуться к диагнозу или фиксу с наибольшим рычагом, не гадая.
Сниппет 1 — referral в +trace
$ dig +trace shop.example.com A
;; received referral from the .com TLD:
example.com. 172800 IN NS ns1.example.net.
example.com. 172800 IN NS ns2.example.net.
;; (Additional section empty)
;; query to ns1.example.net times out
;; query to ns2.example.net times out
;; SERVFAIL Викторина
Completed
Referral от .com перечисляет nameserver'ы, но резолв даёт SERVFAIL. Имена NS — ns1/ns2.example.net. Какое первое прочтение самое полезное?
Heads-up Glue нужен только для in-bailiwick nameserver'ов (ns1.example.com). Эти — в example.net, out-of-bailiwick зоне, которую резолвер резолвит независимо, так что пустой Additional ожидаем, а не баг.
Heads-up 172800 с (2 дня) — нормальный TTL для NS и к таймауту отношения не имеет. Резолв падает потому, что оба nameserver'а example.net недоступны, а не из-за TTL.
Heads-up TLD никогда не держит листовые A-записи; он возвращает делегирование (NS) и перенаправляет дальше. Сбой ниже по цепочке, на nameserver'ах example.net.
Сниппет 2 — правка зонного файла
$ORIGIN example.com.
@ IN SOA ns1.example.com. admin.example.com. (
2026051300 ; serial (was 2026051905)
7200 ; refresh
3600 ; retry
1209600 ; expire
300 ) ; minimum (negative-cache TTL)
@ IN NS ns1.example.com.
@ IN CNAME shop.cdnprovider.net.
www IN CNAME shop.cdnprovider.net. Викторина
Completed
В этой правке зоны ДВА дефекта, которые укусят в продакшене. Какие?
Heads-up 300 с — нормальный TTL для negative cache, а in-zone NS вроде ns1.example.com получает glue из родительского делегирования .com, а не из этого файла. Реальные дефекты — уменьшенный serial и apex CNAME.
Heads-up Refresh (7200) больше retry (3600) — нормальный порядок. Реально ломают уменьшенный serial и запрещённый apex CNAME.
Heads-up CNAME на не-apex метке вроде www, указывающий на другой домен, полностью легален и обычен для CDN. Недопустим именно apex (@) CNAME; второй дефект — уменьшенный serial.
Сниппет 3 — диагностика DNSSEC
$ dig @1.1.1.1 +dnssec api.bank.example A
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41832
;; flags: qr rd ra; QUERY: 1, ANSWER: 0
$ dig @1.1.1.1 +cd api.bank.example A # +cd = checking disabled
;; ->>HEADER<<- status: NOERROR; flags: qr rd ra cd; ANSWER: 1
api.bank.example. 60 IN A 203.0.113.42 Викторина
Completed
Валидирующий резолвер возвращает SERVFAIL, но тот же запрос с +cd возвращает чистую A-запись. Что это доказывает и каков эффект для клиентов?
Heads-up +cd возвращает живой NOERROR-ответ, значит авторитативный работает и отдаёт корректные данные. Сбой в валидации, а не в доступности.
Heads-up DNSSEC проверяет подписи, а не «правильность» IP. +cd показывает, что данные присутствуют; разрыв в цепочке подписей (DS/KSK), а не в неверном IP.
Heads-up Любой валидирующий резолвер (8.8.8.8, Quad9 в том числе) вернёт тот же SERVFAIL, потому что цепочка порвана выше. Успех +cd исключает rate limiting.
Сниппет 4 — конфиг резолвера и замер задержки
# /etc/unbound/unbound.conf (excerpt)
server:
serve-expired: yes
serve-expired-ttl: 86400
$ dig +short @127.0.0.1 whoami.cloudflare TXT CH
"AMS"
$ dig +short @127.0.0.1 example.com A
;; Query time: 70 msec # every query, never cached lower Викторина
Completed
serve-expired включён, ближайший к резолверу PoP Cloudflare — AMS, но example.com стоит 70 мс на каждом запросе и никогда не падает до sub-ms. Какие два прочтения верны?
Heads-up serve-expired отдаёт устаревшие данные быстрее во время сбоев; он никогда не добавляет задержку здоровому запросу. Постоянные 70 мс — сбой кеширования (TTL=0 или отбрасывание при валидации), не связанный с этой директивой.
Heads-up AMS — просто PoP, который ответил (Амстердам); один anycast-хоп нормален. 70 мс на каждом запросе — про то, что ответ не кешируется, а не про выбор PoP.
Heads-up Тёплый кеш возвращает за sub-ms до low-ms. Стабильные 70 мс значат, что каждый запрос делает полный upstream-обход — ответ не попадает в кеш (TTL=0, истечение или отбрасывание DNSSEC).
Итог
Каждый DNS-инцидент читается в артефактах: referral в +trace говорит, нужен ли вообще glue (in-bailiwick vs out-of-bailiwick) и где застрял обход; зонный файл с первого взгляда выдаёт уменьшенный serial и запрещённый apex CNAME; SERVFAIL, исчезающий под +cd, — это разрыв цепочки DNSSEC, почти всегда несовпадение DS-vs-KSK после rollover; а постоянное время запроса значит, что ответ не кешируется, тогда как serve-expired помогает только во время сбоев. Диагностируйте по артефакту, назовите порванное звено, затем чините тот один механизм, на который оно указывает.