Перейти к содержанию

Лабораторная: диагностика DNS

В паре со статьёй: Разрешение DNS и диагностика

Окружение: одна одноразовая VM с доступом в интернет и установленным dig (apt install dnsutils / dnf install bind-utils).

Начальные условия

  1. VM с рабочим интернет-соединением и DNS-резолвингом, подтверждённым командой dig +short example.com, возвращающей IP-адрес.
  2. Доступ root/sudo для редактирования /etc/hosts и, если присутствует, resolvectl.

Инструкции

Часть 1 — Сломайте намеренно

Внесите одну из следующих неисправностей:

  • Перекрытие через hosts-файл: добавьте строку в /etc/hosts, сопоставляющую example.com с 127.0.0.1 (намеренно неверный адрес).
  • Сломанный резолвер: если система использует systemd-resolved, установите несуществующий DNS-сервер: sudo resolvectl dns eth0 192.0.2.254 (зарезервированный, немаршрутизируемый тестовый адрес). На системе без systemd-resolved отредактируйте напрямую /etc/resolv.conf, указав тот же фиктивный адрес.

Часть 2 — Диагностируйте

  1. Выполните dig example.com и dig example.com @8.8.8.8 (внешний сервер, минуя локальную конфигурацию) и сравните два результата.
  2. Выполните getent hosts example.com и сравните с обоими результатами dig.
  3. Определите, основываясь только на этих трёх результатах, находится ли неисправность в /etc/hosts, в локальной конфигурации резолвера, или нигде из этого.

Ожидаемые результаты

  • Неисправность hosts-файла: dig example.com (который НЕ обращается к /etc/hosts — dig общается напрямую с DNS-серверами) вернёт настоящий, корректный адрес. getent hosts example.com (который ДЕЙСТВИТЕЛЬНО следует порядку files, dns из /etc/nsswitch.conf) вернёт вместо этого 127.0.0.1. Это расхождение между dig и getent и есть диагностический сигнал.
  • Неисправность сломанного резолвера: dig example.com (используя системный, теперь сломанный резолвер по умолчанию) завершится таймаутом или явной ошибкой. dig example.com @8.8.8.8 (явно минуя его) завершится успешно. Это расхождение — один работает, другой нет, для абсолютно того же запроса — локализует проблему именно в конфигурации локального резолвера, не в домене и не во всём интернете.

Чек-лист диагностики

  • [ ] Использовали ли вы dig, а не ping, как основной инструмент? (ping даёт только успех/неудачу, без деталей «какой сервер ответил, дошёл ли запрос вообще до настоящего сервера».)
  • [ ] Правильно ли вы определили, был ли задействован /etc/hosts, основываясь именно на расхождении dig и getent (а не на предположении)?
  • [ ] Могли бы вы объяснить, почему dig игнорирует /etc/hosts, тогда как getent hosts (и обычное разрешение имён приложениями) — нет?

Критерии успеха

При любой из двух неисправностей (не зная заранее, какая именно) вы можете утверждать — основываясь только на выводе команд, не на догадке — является ли проблема /etc/hosts, конфигурацией резолвера, или реальным сбоем вышестоящего DNS, используя не более двух команд.

Очистка / откат

# Удалить тестовую запись из /etc/hosts, если добавляли:
sudo sed -i '/example.com/d' /etc/hosts

# Восстановить резолвер на рабочий DNS-сервер:
sudo resolvectl dns eth0 1.1.1.1 8.8.8.8     # systemd-resolved
# — или, без systemd-resolved —
echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf

Убедитесь, что dig +short example.com снова возвращает настоящий адрес, прежде чем считать лабораторное окружение восстановленным.