Администрирование Linux-серверов

Настройка DNS-резолвера в Linux: resolv.conf и systemd-resolved

Как определить источник DNS-настроек в Linux, безопасно изменить постоянную конфигурацию и проверить systemd-resolved, NetworkManager или systemd-networkd.

12 минут
абстрактная иллюстрация разрешения DNS-имён на Linux-сервере
Настройка DNS в Linux начинается с определения владельца конфигурации, а не с редактирования `/etc/resolv.conf`.
Файл /etc/resolv.conf не всегда является постоянным местом настройки DNS: это может быть обычный файл, символическая ссылка или автоматически сформированное представление параметров сети. Сначала определите, какой компонент управляет файлом и DNS для интерфейсов, затем меняйте его постоянную конфигурацию — например, drop-in-файл systemd-resolved, профиль NetworkManager или файл systemd-networkd. Ручная правка /etc/resolv.conf оправданна только если подтверждено, что файл никто не генерирует.

Что содержится в /etc/resolv.conf

/etc/resolv.conf задаёт параметры, с которыми библиотека разрешения имён и другие программы могут обращаться к DNS-резолверу. Формат описан в resolv.conf(5), но отдельные ограничения и поддерживаемые параметры зависят от реализации libc и её версии.

/etc/resolv.conf
nameserver 192.0.2.53
nameserver 198.51.100.53
search corp.example lab.example
options timeout:2 attempts:2

Пример директив resolv.conf

ДирективаНазначение
nameserverIP-адрес DNS-сервера. Если здесь указан 127.0.0.53, приложения обычно обращаются к локальному stub-resolver systemd-resolved, а не непосредственно к внешнему DNS-серверу.
searchСписок поисковых суффиксов для коротких имён. Например, имя db может проверяться как db.corp.example. Порядок, число доменов и правила поиска определяет используемая libc.
domainОдин локальный домен. В типичной реализации libc domain и search взаимоисключающие: действует последняя встретившаяся директива.
optionsДополнительные параметры клиентского резолвера, например число попыток или тайм-аут. Их поддержка и смысл зависят от libc; не переносите набор опций между дистрибутивами без проверки документации.

Короткое имя и поисковый домен

Поисковые домены влияют на запросы неполных имён. Они не заменяют записи DNS и не исправляют недоступность DNS-сервера. Настройка адресов, маршрутов и доступности сервера DNS относится к диагностике сети, а не к настройке резолвера.

Шаг 1. Зафиксируйте текущее состояние и владельца /etc/resolv.conf

Инвентаризация DNS-настроек перед изменением

Выполните эти проверки до редактирования файлов. Тип и цель /etc/resolv.conf нужно сопоставить с активными сетевыми службами и их конфигурацией.

  1. 1
    Сохраните сведения о выпуске и текущем файле
    Зафиксируйте дистрибутив и версию, затем посмотрите тип файла, цель ссылки и содержимое. Схема DNS различается между выпусками и может измениться после установки другого сетевого менеджера.
  2. 2
    Определите, является ли файл ссылкой
    stat покажет тип объекта. readlink без ключей выведет непосредственную цель символической ссылки, а readlink -f — конечный путь после разрешения цепочки ссылок. Для обычного файла readlink без ключей ничего не выведет и завершится с ненулевым кодом.
  3. 3
    Найдите компонент, управляющий сетью и DNS
    Проверьте активность NetworkManager, systemd-networkd и systemd-resolved. Если установлен nmcli, сопоставьте активный профиль с нужным интерфейсом; если установлен networkctl, посмотрите, какие интерфейсы управляются networkd. Для обычного файла дополнительно учитывайте комментарий Generated by … и проверяйте конфигурацию названного DHCP-клиента, resolvconf, cloud-init или другого инструмента. Само наличие процесса ещё не доказывает, что именно он записывает /etc/resolv.conf.
  4. 4
    Сделайте резервную копию до правки
    Сохраните /etc/resolv.conf вместе со сведениями о его типе и цели ссылки, а также содержимое постоянного источника, который будете изменять: например, drop-in-файла resolved, профиля NetworkManager или .network-файла. Копировать только текст из /etc/resolv.conf недостаточно, если это ссылка.
Команда не меняет систему. В выводе `stat` обычный файл будет обозначен как `regular file`; для ссылки будет видно `symbolic link` и её цель.
cat /etc/os-release; stat -c '%F  %N' /etc/resolv.conf; readlink /etc/resolv.conf || true; readlink -f /etc/resolv.conf; sed -n '1,120p' /etc/resolv.conf
Первые строки проверяют распространённые сетевые компоненты и показывают интерфейсы, которыми управляют NetworkManager или systemd-networkd. Последняя строка лишь помогает найти других кандидатов: владельца `/etc/resolv.conf` подтверждайте по цели ссылки, комментариям в файле и конфигурации найденного компонента.
systemctl is-active NetworkManager.service systemd-networkd.service systemd-resolved.service
command -v nmcli >/dev/null && nmcli general status
command -v networkctl >/dev/null && networkctl list
systemctl list-units --type=service --state=running | grep -Ei 'dhcp|resolv|network|cloud' || true

Не заменяйте ссылку обычным файлом без диагностики

Команды вида rm /etc/resolv.conf или принудительное создание нового файла могут разорвать интеграцию с systemd-resolved либо сетевым менеджером. После следующего переподключения интерфейса, продления DHCP-аренды или перезагрузки файл может быть создан заново с другими параметрами.

Шаг 2. Проверьте systemd-resolved и его DNS-данные

systemd-resolved — локальная системная служба для разрешения имён. Она объединяет глобальные параметры и DNS-данные конкретных сетевых каналов (links): адреса серверов, поисковые и маршрутные домены. DHCP обычно передаёт эти данные не напрямую resolved, а через NetworkManager, systemd-networkd либо другой компонент, управляющий интерфейсом.

Это проверка без изменений. `is-active` обычно выводит `active`, если служба запущена. `resolvectl status` показывает глобальные параметры и секции `Link`; команды `resolvectl dns` и `resolvectl domain` дают более краткий список серверов и доменов.
systemctl is-active systemd-resolved.service; resolvectl status; resolvectl dns; resolvectl domain
Вывод:
В `resolvectl status` ищите `Global` и нужный `Link (… )`: DNS Servers, DNS Domain и текущие DNS-настройки интерфейса.

Если systemd-resolved.service не найден, неактивен или команда resolvectl отсутствует, не делайте вывод, что DNS нужно обязательно писать в /etc/resolv.conf: сначала определите сетевой менеджер и генератор файла. Наличие старой совместимой команды systemd-resolve зависит от версии systemd и комплектации дистрибутива; в новой процедуре используйте resolvectl, когда он установлен.

Не переносите поведение между дистрибутивами

Нельзя считать systemd-resolved включённым по умолчанию или заранее назначать владельца /etc/resolv.conf для Ubuntu Server, Debian, RHEL, Rocky Linux либо AlmaLinux без проверки именно установленного выпуска и его документации. На это влияют версия дистрибутива, пакеты, выбранный при установке сетевой стек и последующие изменения администратора.

Как интерпретировать ссылку /etc/resolv.conf при systemd-resolved

Документация systemd описывает несколько допустимых целей ссылки /etc/resolv.conf. Они означают разные способы, которыми приложения взаимодействуют со службой, поэтому цель ссылки нужно учитывать вместе с выводом resolvectl status.

Распространённые варианты, описанные в документации systemd

Цель или вариантЧто видят приложенияПрактический смысл
/run/systemd/resolve/stub-resolv.confnameserver 127.0.0.53 и поисковые доменыПриложения направляют обычные DNS-запросы в локальный stub-resolver, а systemd-resolved выбирает подходящие внешние DNS-серверы.
/run/systemd/resolve/resolv.confСписок известных systemd-resolved внешних DNS-серверов и доменовПриложения могут обращаться к указанным серверам напрямую; при этом часть возможностей локального stub-resolver обходится.
/usr/lib/systemd/resolv.confСтатический минимальный файл с локальным адресом stub-resolverМожет применяться как статическая ссылка, если локальный listener включён и нужен stub-режим.
Обычный файл или ссылка на файл другого компонентаЗависит от генератораЕго могут обслуживать NetworkManager, DHCP-клиент, resolvconf, скрипт интеграции или другой инструмент.

Параметр DNSStubListener= в resolved.conf управляет локальным DNS-listener systemd-resolved. Его документированные значения включают yes, no, udp и tcp; обычное значение по умолчанию — yes, но полагаться на него без проверки выпуска не следует. Если listener отключён через DNSStubListener=no, ссылка на файл с nameserver 127.0.0.53 не подходит: локальный адрес перестаёт принимать такие запросы.

Resolved не строит единый неизменный список «DNS №1, DNS №2» для всех запросов. Он сначала выбирает подходящие links по маршрутным и поисковым доменам: домен с префиксом ~ является маршрутным, а ~. соответствует всему DNS-пространству. Затем служба выбирает серверы в подходящей области. Поэтому VPN с доменом ~corp.example и обычный интерфейс с публичным DNS могут корректно обслуживать разные имена.

Ветка A: глобальная настройка systemd-resolved

Глобальные параметры systemd-resolved подходят, когда системный путь разрешения имён действительно использует эту службу и для VPN или отдельных интерфейсов не требуется иная маршрутизация DNS. Основной файл — /etc/systemd/resolved.conf; для локального изменения обычно удобнее отдельный drop-in в /etc/systemd/resolved.conf.d/. При этом глобальный DNS= не отменяет автоматически серверы, полученные для отдельных интерфейсов: systemd-resolved может использовать их вместе с глобальными серверами в зависимости от доменов и маршрутизации. Если такие серверы нужно исключить, отключите их получение в постоянной конфигурации владельца подключения, например через ignore-auto-dns в профиле NetworkManager.

В systemd конфигурация может поставляться из /usr/lib/, /usr/local/lib/, /run/ и /etc/. Для основного resolved.conf используется первый найденный файл по приоритету каталогов. Drop-in-файлы из каталогов *.conf.d объединяются в лексикографическом порядке; одноимённый файл из каталога с более высоким приоритетом заменяет вариант с тем же именем из нижестоящего каталога. Для локальных настроек используйте уникальное имя, например 60-local-dns.conf, и не редактируйте файлы поставщика в /usr/lib.

/etc/systemd/resolved.conf.d/60-local-dns.conf
[Resolve]
# Замените адреса на разрешённые для вашей сети.
DNS=192.0.2.53 198.51.100.53
Domains=corp.example

# Не включайте без необходимости: применяется, только когда служба
# не знает других DNS-серверов.
# FallbackDNS=203.0.113.53

# Оставляйте параметр только при осознанном выборе stub-режима.
# DNSStubListener=yes

DNS= задаёт глобальные DNS-серверы. Domains= задаёт глобальные поисковые либо маршрутные домены: запись без ~ — поисковый домен, ~domain — маршрутный. FallbackDNS= используется только когда systemd-resolved не получил иных DNS-серверов; это не резервный сервер в обычной последовательности каждого запроса. DNSStubListener= настраивает локальный listener, а не внешние DNS-серверы.

Применение глобальной настройки resolved

  1. 1
    Создайте каталог и drop-in-файл
    Создайте /etc/systemd/resolved.conf.d/, если его нет, и сохраните в нём файл с параметрами. Перед этим скопируйте существующие локальные файлы resolved.conf и resolved.conf.d, если они будут затронуты.
  2. 2
    Перезапустите только resolved в согласованное окно
    После изменения конфигурации используйте systemctl restart systemd-resolved.service. Не предполагается, что reload поддержан во всех выпусках и пакетных сборках. Перезапуск может кратковременно прервать локальное разрешение имён.
  3. 3
    Проверьте фактически принятые параметры
    Проверьте resolvectl status, а затем выполните запрос через resolvectl query. Если /etc/resolv.conf указывает на stub-файл, убедитесь, что в нём по-прежнему есть 127.0.0.53 и что listener не был отключён.
Команда создаёт каталог при необходимости, перезапускает службу и выводит её текущую конфигурацию. Сам файл drop-in должен быть создан до запуска команды.
sudo install -d -m 0755 /etc/systemd/resolved.conf.d && sudo systemctl restart systemd-resolved.service && resolvectl status

Осторожно при удалённом доступе

Изменение DNS способно нарушить доступ к ресурсам по именам, репозиториям, LDAP и другим зависимостям. Если подключение к серверу или автоматизация используют DNS-имя, сохраните рабочую сессию и план возврата. Общий порядок управления службами описан в статье systemd и systemctl: управление службами и автозагрузкой Linux.

Ветка B: DNS для интерфейса, VPN или отдельного подключения

Не задавайте DNS только в глобальном resolved.conf, если сервер одновременно подключён к обычной сети и VPN, имеет несколько uplink-интерфейсов или должен отправлять запросы к отдельному домену через конкретный канал. В такой схеме постоянным источником обычно является профиль соединения NetworkManager, .network-файл systemd-networkd либо иной штатный механизм владельца интерфейса.

NetworkManager: изменить профиль соединения

Для NetworkManager 1.x, где доступны документированные свойства ipv4.dns, ipv4.dns-search и ipv4.ignore-auto-dns, DNS задают в профиле подключения через nmcli. При ipv4.ignore-auto-dns yes NetworkManager игнорирует автоматически полученные для этого профиля DNS-серверы и поисковые домены и использует заданные вручную значения; без этого параметра ручной список может объединяться с автоматическим. Для IPv6 аналогично проверьте свойства ipv6.dns и ipv6.ignore-auto-dns в документации установленной версии.

Сначала найдите имя активного профиля и сохраните его текущие `ipv4.dns`, `ipv4.dns-search` и `ipv4.ignore-auto-dns` для возврата.
nmcli connection show --active; nmcli connection show "$PROFILE"
# Подставьте имя профиля и DNS-адреса своей сети.
sudo nmcli connection modify "$PROFILE" \
  ipv4.dns "192.0.2.53 198.51.100.53" \
  ipv4.dns-search "corp.example" \
  ipv4.ignore-auto-dns yes

# Переподключение может оборвать SSH через этот интерфейс.
sudo nmcli connection up "$PROFILE"

Команда connection up повторно активирует профиль и может изменить адрес, маршрут или DNS-состояние соединения. На удалённом сервере применяйте её только с доступом к консоли либо в согласованное окно. Если NetworkManager передаёт параметры в systemd-resolved, результат появится в секции соответствующего Link в resolvectl status; способ создания /etc/resolv.conf при этом остаётся политикой конкретной системы.

systemd-networkd: задать per-link DNS в .network

В выпусках systemd, где systemd.network(5) документирует ключи [Network] DNS= и Domains=, эти параметры задают DNS и домены для конкретного link. systemd-networkd хранит и передаёт per-link-параметры службе-резолверу, но сам по себе не обслуживает /etc/resolv.conf: этот файл по-прежнему может быть ссылкой systemd-resolved или результатом работы другого компонента.

/etc/systemd/network/10-uplink.network
[Match]
Name=enp1s0

[Network]
# Остальные параметры работающего подключения не удаляйте.
DNS=192.0.2.53
DNS=198.51.100.53
Domains=corp.example

Не создавайте минимальный .network поверх неизвестной действующей конфигурации: файл может также содержать DHCP, адреса, маршруты и другие параметры. После правки используйте способ применения, документированный для установленной версии networkctl и systemd-networkd — в версиях с поддержкой обычно применяют networkctl reload, а затем networkctl reconfigure ИНТЕРФЕЙС. Если требуется перезапуск networkd, планируйте его как сетевое изменение, поскольку он способен разорвать подключение.

Ветка C: когда допустима ручная настройка resolv.conf

Статический /etc/resolv.conf можно редактировать вручную, если проверка показала, что это обычный файл и его не обслуживают NetworkManager, DHCP-клиент, resolvconf, cloud-init, скрипт интеграции или другой инструмент. Это чаще встречается в специально собранных, изолированных или минимальных системах, но не следует считать правилом для конкретного семейства дистрибутивов.

  • Проверьте, что /etc/resolv.conf — regular file, а не ссылка.
  • Проверьте активные сетевые компоненты и их конфигурацию, а также комментарии в начале файла вроде Generated by ….
  • Отключайте автоматическое получение DNS только в его настоящем источнике — например, в профиле NetworkManager, — а не заменой файла.
  • После повторной активации интерфейса или перезагрузки системы снова проверьте файл. Это практический способ убедиться, что компонент не формирует его заново с прежними параметрами.

Проверка разрешения имён после изменения

Проверяйте два разных пути. В GNU libc команда getent hosts ИМЯ обращается к базе NSS hosts; результат зависит от /etc/nsswitch.conf и может включать не только DNS, но и /etc/hosts, LDAP, mDNS или другие источники. resolvectl query ИМЯ проверяет обработку запроса именно systemd-resolved. Эти результаты могут различаться, и это не всегда ошибка.

Первую часть выполняет GNU `getent` и она проверяет системное разрешение по правилам NSS. Вторая применима при работающем systemd-resolved и показывает ответ, полученный через эту службу.
getent hosts example.com; resolvectl query example.com

Почему недостаточно dig @сервер

Прямой запрос DNS-клиентом к указанному адресу, например dig @DNS_СЕРВЕР имя, полезен для проверки конкретного сервера, но обходит обычный системный путь: NSS, /etc/nsswitch.conf, локальный stub-resolver, маршрутизацию доменов и выбор интерфейса. Он не заменяет getent и resolvectl query.

Если resolvectl query показывает тайм-аут или сервер недоступен, а конфигурация выбрана верно, переходите к проверке IP-связности, маршрута и правил фильтрации в материале по networking. Если сама служба не запускается, не меняйте DNS-файлы наугад: используйте порядок из статьи Служба systemd не запускается: диагностика ошибок и восстановление.

Как вернуть предыдущую конфигурацию

  1. Верните изменение в том постоянном источнике, который меняли: удалите или исправьте созданный drop-in resolved.conf, восстановите прежние свойства профиля NetworkManager либо прежний .network-файл.
  2. Примените изменение штатно для владельца конфигурации: перезапустите systemd-resolved после изменения его файлов, повторно активируйте профиль NetworkManager либо примените конфигурацию networkd способом, поддержанным установленным выпуском.
  3. Не подменяйте /etc/resolv.conf, если исходно это была символическая ссылка. Восстановите исходный тип файла и точную цель ссылки из сохранённого снимка.
  4. Повторите stat, readlink и getent hosts. Если система использует systemd-resolved и команда resolvectl установлена, дополнительно выполните resolvectl status и resolvectl query, чтобы подтвердить не только текст конфигурации, но и фактическое разрешение имени.

Возврат должен восстанавливать источник, а не только результат

Восстановление старого текста /etc/resolv.conf не вернёт рабочую схему, если до изменения файл генерировался NetworkManager или systemd-resolved. Верните профиль, drop-in или файл интерфейса, который был владельцем настройки, и дайте этому компоненту сформировать текущее состояние заново.

Термины в статье

Имя хоста — идентификатор узла в сети и операционной системе, используемый для отображения, журналирования и разрешения имени в IP-адрес при наличии DNS или hosts.
Процесс — экземпляр выполняемой программы в Linux с PID, виртуальным адресным пространством, состоянием и связанными с ним ресурсами.
Системная служба — программный компонент, которым ОС управляет как логической единицей для фонового выполнения задач или предоставления функций программам и пользователям.
AlmaLinux — корпоративный дистрибутив Linux, поддерживаемый сообществом и AlmaLinux OS Foundation, ориентированный на совместимость с интерфейсами и экосистемой RHEL.
Cloud-Init — система начальной настройки облачных экземпляров, применяющая метаданные и пользовательские данные при первом запуске виртуальной машины.
Debian — универсальный дистрибутив Linux с пакетами DEB и системой APT, известный консервативной веткой Stable и разделением репозиториев по веткам разработки.
DNS-резолвер — программный компонент или служба, которая выполняет DNS-запросы от имени клиента и возвращает найденные записи, используя кэш и другие DNS-серверы.
journalctl — консольная утилита чтения и фильтрации журнала systemd, выводящая сообщения по времени, юниту, загрузке системы, приоритету и другим полям.
resolv.conf — конфигурационный файл резолвера DNS в Linux и Unix, задающий серверы имён, поисковые домены и параметры разрешения имён.
RHEL — корпоративный дистрибутив Linux от Red Hat с фиксированными основными версиями, сертификационной экосистемой и моделью сопровождения, зависящей от подписки.
Rocky Linux — корпоративный дистрибутив Linux, создаваемый из исходных пакетов экосистемы RHEL и ориентированный на совместимость с RHEL без использования его товарных знаков.
systemctl — командная утилита управления systemd, которая запускает и останавливает юниты, показывает их состояние и настраивает автоматическую активацию.
systemd — система инициализации и менеджер служб Linux, управляющий службами и другими ресурсами как объектами unit, обычно описанными unit-файлами.
systemd-resolved — служба systemd для локального разрешения DNS-имён, объединяющая DNS-настройки интерфейсов, кэширование и выбор DNS-серверов.
Ubuntu Server — серверный вариант дистрибутива Ubuntu на базе Debian с APT и типовыми средствами автоматизации, доступный в виде установочных и готовых образов.

Вопросы по теме

Все вопросы и ответы

Можно ли просто отредактировать /etc/resolv.conf?

Нет, сначала нужно определить источник конфигурации. Проверьте тип /etc/resolv.conf, цель символической ссылки и комментарии в начале файла. Обычный файл в выводе stat обозначается как regular file; ссылка — как symbolic link. Для ссылки используйте readlink и readlink -f, чтобы увидеть непосредственную и конечную цель.

Если файл создаёт NetworkManager, меняйте DNS в профиле подключения. Если параметры передаются через systemd-networkd, корректируйте действующий .network-файл. При использовании systemd-resolved глобальные настройки обычно размещают в drop-in-файле /etc/systemd/resolved.conf.d/. Не заменяйте ссылку командой rm или созданием нового файла: это может нарушить интеграцию с резолвером или сетевым менеджером.

Перед изменением сохраните не только текст /etc/resolv.conf, но и его тип, цель ссылки и содержимое постоянного источника настроек. После повторной активации интерфейса или перезагрузки убедитесь, что DNS-параметры не были сформированы заново.

Что означает nameserver 127.0.0.53 в resolv.conf?

Запись nameserver 127.0.0.53 направляет обычные DNS-запросы на локальный адрес systemd-resolved. Часто /etc/resolv.conf при этом является ссылкой на /run/systemd/resolve/stub-resolv.conf либо на статический файл /usr/lib/systemd/resolv.conf.

Не следует заменять этот адрес внешним DNS-сервером только потому, что он выглядит как loopback-адрес. systemd-resolved может выбирать DNS-серверы отдельно для разных каналов: например, запросы к домену VPN могут идти через VPN-интерфейс, а публичные имена — через обычную сеть. Это определяется маршрутными и поисковыми доменами.

Проверьте resolvectl status, resolvectl dns и resolvectl domain. Если параметр DNSStubListener=no отключил локальный listener, конфигурация с 127.0.0.53 не подходит: локальный адрес перестаёт принимать такие запросы.

Почему getent hosts и resolvectl query дают разные результаты?

Это не всегда ошибка. getent hosts проверяет системное разрешение имён через NSS и настройки /etc/nsswitch.conf; помимо DNS там могут участвовать /etc/hosts, LDAP, mDNS и другие источники. resolvectl query проверяет обработку запроса именно службой systemd-resolved. Поэтому команды могут показать разные ответы или поведение.

FallbackDNS заменяет основной DNS-сервер при сбое?

Нет. В systemd-resolved параметр FallbackDNS= используется только когда служба не получила никаких других DNS-серверов. Это не резервный сервер, который автоматически добавляется к обычной последовательности запросов при недоступности основного DNS. Глобальные и полученные для интерфейсов серверы могут использоваться по правилам доменной маршрутизации.

Можно ли проверить DNS командой dig @DNS_СЕРВЕР?

Да, но только для проверки конкретного DNS-сервера. dig @DNS_СЕРВЕР имя обходит обычный системный путь разрешения: NSS, /etc/nsswitch.conf, локальный stub-resolver, выбор интерфейса и маршрутизацию доменов. Для проверки системного разрешения используйте getent hosts, а для systemd-resolved — resolvectl query.