👋 Привет, сетевой друг!

Сегодня разберём, как быстро диагностировать проблемы с DNS-инфраструктурой, когда все тормозит, но вообще непонятно где именно.

🟣Проверка задержек резолва без кэша: dig по умолчанию может брать данные из кэша, и создаёт иллюзию, что всё быстро. Нас интересует честный lookup.

dig +trace +nodnssec example.com

Смотрите, на каком уровне тормозит: корень, TLD, авторитетный сервер или клиентский резолвер.

🟣Выявление проблем с рекурсией на локальном резолвере: Если DNS-сервер зависает или «захлёбывается», это видно по времени ответа.

dig @127.0.0.1 example.com +stats

Если Query time скачет выше 200–300 мс, то смотрим в сторону max-clients, перегретых TCP-потоков или огромного списка ACL.

🟣Диагностика проблем с DNS-over-UDP и фрагментацией: Большие ответы (DNSSEC, SPF, SRV) могут ломаться, если MTU на пути маленький.

dig example.com DNSKEY +dnssec +bufsize=4096

Если падает на UDP, проверьте MTU и EDNS, переключись на TCP для теста.

🟣Анализ кэша и подозрительных значений TTL: Бывает, что домены установили слишком маленький TTL, и резолвер умирает под нагрузкой.

rndc dumpdb -cache
grep -i example /var/cache/bind/dump.db

Подозрительные записи с TTL < 60 секунд - потенциальная причина скачков нагрузки.

🟣Проверка задержек внутри сети для рекурсивного резолва: Чтобы понять, не ломается ли DNS на межсетевом пути.

dig example.com @dns01 -4 +noedns
dig example.com @dns02 -6 +noedns

Если IPv6 даёт резкие лаги - причина в маршрутизации или firewall.

Серверная Админа | #network