DNS: команды для управления системой разрешения доменных имен | xnix

При неполадках системы преобразования доменных имен в IP-адреса часто используют следующие команды:

Давайте разберем каждую из этих команд. Все они относятся к управлению системой DNS (система доменных имен) в современных дистрибутивах Linux (особенно с systemd).

resolvectl status

Назначение: показать текущее состояние, т. е. настройки и статистика встроенного DNS-резолвера (клиента) systemd-resolved.

Эта команда выводит подробную информацию о том, как ваш компьютер в данный момент настроен для разрешения доменных имен:

● Глобальные настройки: какие DNS-серверы используются по умолчанию (глобально).
● Настройки интерфейсов: для каждого сетевого интерфейса (например eth0, wlan0) показано, какой DNS-сервер получен по DHCP или задан вручную.
● Домены поиска: список доменов, которые автоматически подставляются при вводе коротких имен (например, если вы ввели server, а в поиске стоит home.lan, система попытается найти server.home.lan).
● Текущий DNSSEC: включена ли проверка цифровых подписей DNS (защита от подделки).
● Статистика: количество успешных и неудачных запросов.

Когда использовать: для диагностики — чтобы понять, какой DNS-сервер использует система в данный момент (например, ваш роутер, Google DNS или провайдер).

Пример вывода команды resolvectl status:

$ resolvectl status
Global
         Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (enp0s31f6)
    Current Scopes: DNS LLMNR/IPv4 mDNS/IPv4
         Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.a.b
       DNS Servers: 192.168.a.b 192.168.c.d

Link 3 (wwan0)
    Current Scopes: none
         Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 4 (wlp0s20f3)
    Current Scopes: none
         Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 5 (docker0)
    Current Scopes: none
         Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported

Это снимок состояния systemd-resolved, и здесь видно, что система использует гибкую логику выбора DNS в зависимости от того, какой сетевой интерфейс активен.

journalctl -f -u systemd-resolved

Эта команда состоит из трех частей. Разберем ее по элементам:

journalctl — утилита для просмотра системных логов (журналов) systemd.

-u systemd-resolved — фильтр, показывающий логи только от конкретного юнита (службы) с именем systemd-resolved.service.

-f (от follow) — режим "слежения". Журнал не выводится один раз и не закрывается, а постоянно висит в терминале и показывает новые записи по мере их появления (аналог tail -f).

Назначение: в режиме реального времени наблюдать за работой локального DNS-резолвера.

Когда использовать: это главный инструмент для отладки проблем с сетью. Вы открываете этот лог, пытаетесь открыть сайт в браузере или выполняете ping, и сразу видите в терминале:

● Какой запрос пришел и когда.
● Какой DNS-сервер был опрошен.
● Сколько времени занял ответ.
● Если есть ошибки (таймауты, отказы сервера, проблемы с DNSSEC), они появятся здесь мгновенно.

resolvectl query mail.ru

Назначение: вручную отправить запрос на разрешение доменного имени конкретно через systemd-resolved, минуя другие утилиты (такие как ping или dig), и получить детальный технический ответ.

Эта команда показывает не просто IP-адрес, а полный маршрут запроса:

● Какой интерфейс был использован для запроса.

● С какого DNS-сервера пришел ответ (например, с локального кеша, с сервера провайдера или с роутера).

● Все найденные типы записей:

A (IPv4-адрес) — например, `94.100.180.200`.
AAAA (IPv6-адрес) — если он есть.
CNAME (каноническое имя/псевдоним) — если домен перенаправляет на другой адрес.

● Статус аутентификации DNSSEC (подтверждена ли подпись).

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

[Связка всех трех команд (пример сценария)]

Представьте, что сайт mail.ru стал плохо открываться.

1. Диагностика: вы вводите `resolvectl status`, чтобы убедиться, что ваш компьютер вообще видит DNS-сервер (например, вы видите, что интерфейс wlan0 получил DNS 8.8.8.8).

2. Мониторинг: вы открываете вторую вкладку терминала и запускаете `journalctl -f -u systemd-resolved`, чтобы видеть живые ошибки.

3. Проверка: в первой вкладке вы пишете `resolvectl query mail.ru`.

● Если команда выдала IP-адрес — значит, резолвер работает, проблема не в DNS, а в самом подключении к сайту.
● Если команда выдала ошибку `DNSSEC validation failed` — вы увидите это и в логе, и в ответе на запрос, и поймете, что проблема в настройках безопасности.

Файл /etc/resolv.conf это основной конфигурационный файл для системного резолвера (набора функций в стандартной C-библиотеке glibc), который используется всеми приложениями для преобразования доменных имен в IP-адреса. Его можно представить как "шпаргалку" для всей системы, в которой указано, куда обращаться за DNS-информацией.

Основные директивы файла. Файл состоит из текстовых директив. Наиболее важные из них:

● nameserver IP-адрес: определяет IP-адрес DNS-сервера, к которому система будет обращаться. Можно указать до трех серверов; запросы будут отправляться в порядке их перечисления, пока один из них не ответит.
● search домен1 домен2 ...: задает список доменов для поиска, когда вы вводите неполное имя (без точки). Например, при `search my.lan home.arpa` и запросе `server` система попытается разрешить `server.my.lan`, затем `server.home.arpa`. Полезно для локальных сетей, но может создавать лишний трафик.
● options – позволяет настраивать поведение резолвера, например, `timeout:n` (время ожидания ответа) или `ndots:n` (количество точек в имени, при котором поиск по `search` отключается).

Если файл отсутствует, система по умолчанию будет обращаться только к серверу на локальной машине (`127.0.0.1`).

Как создается resolv.conf? В современных дистрибутивах Linux файл /etc/resolv.conf редко создается вручную. Его созданием и обновлением автоматически занимаются сетевые менеджеры:

NetworkManager: обычно это основной менеджер. При загрузке системы он создает файл на основе параметров, полученных по DHCP, VPN или указанных вручную. Он может управлять файлом напрямую или через символическую ссылку на /run/NetworkManager/resolv.conf.

systemd-resolved: более современный системный DNS-резолвер. Часто resolv.conf является символической ссылкой на управляемый им файл (/run/systemd/resolve/resolv.conf), через который он транслирует свою конфигурацию для старых приложений.

resolvconf (утилита): специальный фреймворк, агрегирующий DNS-информацию от разных источников (DHCP, VPN) в единый файл. Программы не пишут прямо в resolv.conf, а регистрируют свои настройки через `resolvconf -a`.

Как /etc/resolv.conf удаляется, при каких условиях? Файл не "удаляется" целенаправленно. Он может перестать существовать в следующих случаях:

1. Системная ошибка: если во время загрузки не запустился основной сетевой менеджер (NetworkManager), файл может не быть создан.
2. Ручное удаление: вы можете удалить файл командой `rm /etc/resolv.conf`. Однако при следующем перезапуске сети или загрузке системы менеджер (если он не отключен) создаст его заново.
3. Переключение на ручное управление: в некоторых дистрибутивах можно деактивировать автоматическое управление, создав конфигурацию `dns=none` для NetworkManager. После этого файл может остаться, но менеджер перестанет его обновлять, что позволит редактировать его вручную.

Как resolv.conf работает совместно с другими настройками конфигурации DNS? Файл /etc/resolv.conf это низкоуровневое звено, с которым взаимодействуют все приложения. Он не конфликтует, а "впитывает" в себя настройки из более высокоуровневых систем:

1. Источник → Менеджер: вы настраиваете DNS в NetworkManager (через GUI) или в конфигурационных файлах systemd-resolved (файл /etc/systemd/resolved.conf). Эти настройки являются источником истины.
2. Менеджер → /etc/resolv.conf: Менеджер транслирует эти высокоуровневые настройки и записывает их в /etc/resolv.conf. Таким образом, он служит универсальным интерфейсом для всех приложений, которые используют стандартную библиотеку glibc.
3. Приложение → Библиотека → /etc/resolv.conf: когда вы запускаете `ping mail.ru`, ваша программа вызывает функцию gethostbyname() из библиотеки glibc. Эта функция в первую очередь читает файл /etc/resolv.conf, чтобы узнать, к какому DNS-серверу обращаться.