TGViewer
DevOps Ready | IT DevOps Ready | IT @devops_ready · 7.63K subscribers
Post #1125 1.15K
Диагностика проблем с DNS в Linux!

Многие сетевые проблемы на Linux-серверах оказываются связаны не с firewall, маршрутизацией или приложением, а именно с DNS. Симптомы обычно такие: curl зависает, пакетный менеджер не работает, API недоступен по домену, но по IP всё открывается.

В таких случаях сначала стоит проверить, как система резолвит DNS. Первое, что нужно посмотреть — какие DNS-серверы используются системой.
cat /etc/resolv.conf


В классических системах этого достаточно. Но в современных дистрибутивах с systemd-resolved файл часто указывает только на локальный stub-resolver.
nameserver 127.0.0.53


Если используется systemd-resolved, реальные DNS лучше смотреть так:
resolvectl status


Команда показывает активные DNS-серверы для интерфейсов и текущее состояние resolver’а.

Дальше стоит проверить, как система реально разрешает имя.
getent hosts google.com


Это полезнее, чем кажется. В отличие от dig и nslookup, getent использует системный механизм разрешения имён и ближе к тому, как работают реальные приложения. Если getent не работает, а dig работает — проблема обычно в локальной конфигурации.

Чтобы исключить сам DNS-сервер, полезно сделать прямой запрос.
dig google.com @8.8.8.8


Или через Cloudflare:
dig google.com @1.1.1.1


Так быстро становится понятно, проблема локальная или внешняя.

Даже если DNS отвечает, стоит посмотреть время ответа.
dig google.com


Смотри на строку:
;; Query time: X msec


Если нужно проверить весь путь разрешения, помогает trace.
dig +trace google.com


Также бывает полезно проверить reverse DNS.
dig -x 8.8.8.8


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

Если используется systemd-resolved, можно очистить локальный кэш.
sudo resolvectl flush-caches


А затем посмотреть статистику.
resolvectl statistics


Если приложение жалуется на DNS, но dig работает корректно, стоит проверить NSS.
cat /etc/nsswitch.conf


Особенно строку hosts, потому что она определяет порядок источников разрешения имён.

Для финальной диагностики полезно посмотреть DNS-трафик в реальном времени.
sudo tcpdump -ni any port 53


🔥 Вывод: хорошая DNS-диагностика обычно начинается с трёх вещей: проверки системного resolver’а, прямых запросов к DNS-серверам и анализа сетевого трафика. Такой подход позволяет найти большинство DNS-проблем намного быстрее, чем полный разбор всей сетевой подсистемы.

🚪 Linux Ready | #практика
  • 🔥 14
  • 👍 10
  • ❤ 6
More from @devops_ready
  1. Oct 2, 2026Знали, почему настройки systemd-сервиса лучше менять через systemctl edit? Допустим, прило…
  2. Oct 2, 2026⚡️5 фундаментальных курсов по ИБ по цене одного Это предложение для тех, кто готов войти в…
  3. Oct 2, 2026Этот инструмент поможет поять из чего на самом деле состоит Docker-образ! Он содержит терм…
  4. Oct 1, 2026Проверяем итоговую конфигурацию Docker Compose перед запуском! Когда проект использует баз…
  5. Oct 1, 2026🔄 Безопасный арсенал практических инструкций, курсов и инструментов 👩‍💻 Linux & Bash 🤔…
  6. Oct 1, 2026Шпаргалка по жизненному циклу Pod в Kubernetes! На картинке показано, как запрос проходит…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →