systemd-resolved (Русский)

Состояние перевода:
На этой странице представлен перевод статьи
systemd-resolved
. Дата последней синхронизации: 23 мая 2024. Вы можете
помочь
синхронизировать перевод, если в английской версии произошли
изменения
.
Ссылки по теме
systemd-networkd (Русский)
Разрешение доменных имён
Avahi (Русский)
systemd-resolved
— служба
systemd
, выполняющая разрешение сетевых имён для локальных приложений посредством
D-Bus
,
NSS
-службы
resolve
(см.
nss-resolve(8)
) или локальной слушающей DNS-заглушки на адресе
127.0.0.53
. Подробнее об использовании см.
systemd-resolved(8)
.
Установка
systemd-resolved
входит в пакет
systemd
, который установлен по умолчанию.
Настройка
systemd-resolved
работает как распознаватель для
системы доменных имён (DNS)
(включая
DNSSEC
и
DNS over TLS
),
Multicast DNS (mDNS)
и
Link-Local Multicast Name Resolution (LLMNR)
.
Настройки распознавателя можно изменить в файле
/etc/systemd/resolved.conf
и/или с помощью drop-in файлов с расширением
.conf
в каталоге
/etc/systemd/resolved.conf.d/
. Смотрите
resolved.conf(5)
.
Для запуска
systemd-resolved
запустите
и
включите
службу
systemd-resolved.service
.
Совет
Чтобы лучше понимать контекст выборов и переключателей, включите для
systemd-resolved
сохранение подробной отладочной информации по инструкции в статье
systemd#Диагностика службы
.
DNS
Программы, использующие
getaddrinfo(3)
из glibc (или с аналогичным поведением), будут работать из коробки, поскольку по умолчанию
/etc/nsswitch.conf
настроен на использование
nss-resolve(8)
, если он доступен.
Чтобы
разрешение доменных имён
работало в программах, которые считывают файл
/etc/resolv.conf
напрямую, таких как веб-браузеры,
Go
и
GnuPG
,
systemd-resolved
предоставляет четыре различных режима для работы с этим файлом: stub, static, uplink и foreign. Они описаны в
systemd-resolved(8) § /ETC/RESOLV.CONF
. В данной статье рассматривается только stub — рекомендуемый режим, который использует
/run/systemd/resolve/stub-resolv.conf
.
Файл-заглушка
/run/systemd/resolve/stub-resolv.conf
содержит
127.0.0.53
в качестве единственного DNS-сервера, а также список доменов для поиска. Это рекомендуемый режим работы, с помощью которого конфигурация
systemd-resolved
будет применяться для всех клиентов. Для его использования создайте символическую ссылку
/etc/resolv.conf
, указывающую на этот файл:
# ln -sf ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
Примечание
Целевой путь символической ссылки, содержащий
../
в начале, является путём
относительно расположения символической ссылки
, а не относительно текущего рабочего каталога.
Неправильная настройка
/etc/resolv.conf
приведёт к поломке разрешения доменных имён.
Создать символическую ссылку
/etc/resolv.conf
в окружении
arch-chroot
не получится, потому что в нём этот файл подключается из основной системы через bind-монтирование. Создавайте ссылку, не находясь в chroot, например:
# ln -sf ../run/systemd/resolve/stub-resolv.conf
/mnt
/etc/resolv.conf
Выбор DNS-серверов
Совет
Узнать, какие серверы
systemd-resolved
использует в данный момент, можно командой
resolvectl status
.
Автоматически
systemd-resolved
работает из коробки с
сетевыми менеджерами
, использующими файл
/etc/resolv.conf
. Никаких дополнительных настроек не требуется, поскольку
systemd-resolved
будет автоматически обнаружен при переходе по символической ссылке
/etc/resolv.conf
. Во всяком случае, это работает для
systemd-networkd
,
NetworkManager
и
iwd
.
Тем не менее, если какой-то
DHCP
- или
VPN
-клиент настраивает сервера имён и домены поиска с помощью
resolvconf
(список использующих
resolvconf
программ приведён в статье
openresolv#Пользователи
), то необходимо дополнительно установить пакет
systemd-resolvconf
, который предоставляет символическую ссылку
/usr/bin/resolvconf
.
Примечание
systemd-resolved
имеет ограниченный
resolvconf
-интерфейс и может не работать с некоторыми клиентами, подробнее см.
resolvectl(1) § COMPATIBILITY WITH RESOLVCONF(8)
.
systemd-resolvconf
работает только при запущенном
systemd-resolved.service
. Если вы не используете
systemd-resolved
, убедитесь, что пакет
systemd-resolvconf
удалён, иначе он может создать проблемы с некоторыми сетевыми программами, которые проверяют наличие исполняемого файла
/usr/bin/resolvconf
.
Вручную
В режимах stub и static можно назначить произвольные DNS-серверы, указав их в файле
resolved.conf(5)
:
/etc/systemd/resolved.conf.d/dns_servers.conf
[Resolve]
DNS=192.168.35.1 fd7b:d0bd:7a6e::1
Domains=~.
Примечание
Если не указать в файле
resolved.conf(5)
опцию
Domains=~.
, то
systemd-resolved
может использовать DNS-серверы из настроек отдельных сетевых интерфейсов, если параметр
Domains=~.
в них есть.
Данная опция не повлияет на запросы доменных имён, которые совпадают с каким-то более точным поисковым доменом из настроек интерфейса — разрешение таких имён будет выполняться посредством соответствующих "интерфейсных" DNS-серверов.
Подробнее о настройках для сетевых интерфейсов см.
systemd-networkd#Файлы network
.
Резерв
Если
systemd-resolved
не получает адреса DNS-серверов от
сетевого менеджера
и никакие сервера не были настроены
вручную
, то он использует резервные DNS-адреса. Таким образом, разрешение доменных имён работает всегда.
Примечание
В качестве резервных используются следующие сервера: Cloudflare, Quad9 и Google. Сервера и их порядок определены в
файле PKGBUILD пакета systemd
.
Изменить адреса можно с помощью параметра
FallbackDNS
в файле
resolved.conf(5)
, например:
/etc/systemd/resolved.conf.d/fallback_dns.conf
[Resolve]
FallbackDNS=127.0.0.1 ::1
Чтобы полностью отключить функциональность резервных DNS-серверов, задайте параметр
FallbackDNS
без указания адреса:
/etc/systemd/resolved.conf.d/fallback_dns.conf
[Resolve]
FallbackDNS=
DNSSEC
Важно
Поддержка DNSSEC в systemd-resolved является
экспериментальной и неполной
.
Проверка
DNSSEC
настраивается параметром
DNSSEC
в файле
resolved.conf(5)
.
DNSSEC=allow-downgrade
— проверка выполняется только в том случае, если опрашиваемый сервер её поддерживает.
DNSSEC=true
— проверка выполняется всегда; если сервер не поддерживает DNSSEC, то разрешение доменных имён работать не будет. Пример:
/etc/systemd/resolved.conf.d/dnssec.conf
[Resolve]
DNSSEC=true
Примечание
Если ваш DNS-сервер не поддерживает DNSSEC и вы испытываете проблемы в стандартном (используется по умолчанию) allow-downgrade-режиме (см.
systemd issue 10579
), попробуйте полностью отключить DNSSEC в
systemd-resolved
параметром
DNSSEC=false
.
systemd-resolved
может отключить DNSSEC после нескольких неудачных попыток выполнить проверку. Если задано значение
DNSSEC=true
, то разрешение имён вообще перестанет работать. См.
systemd issue 9867
.
Проверьте, работает ли DNSSEC, отправив запрос к домену с неправильной подписью:
$ resolvectl query badsig.go.dnscheck.tools
badsig.go.dnscheck.tools: resolve call failed: DNSSEC validation failed: invalid
Затем проверьте домен, подпись которого в порядке:
$ resolvectl query go.dnscheck.tools
go.dnscheck.tools: 2604:a880:400:d0::256e:b001 -- link: enp2s0
                   142.93.10.179               -- link: enp2s0

-- Information acquired via protocol DNS in 122.2ms.
--
Data is authenticated: yes
; Data was acquired via local or encrypted transport: no
-- Data from: network
DNS over TLS
DNS over TLS по умолчанию отключен. Чтобы его включить, задайте параметр
DNSOverTLS
в разделе
[Resolve]
файла
resolved.conf(5)
. Чтобы включить проверку сертификата DNS вашего провайдера, добавьте соответствующее имя хоста в параметр
DNS
в формате
ip_адрес
#
имя_хоста
. Например:
/etc/systemd/resolved.conf.d/dns_over_tls.conf
[Resolve]
DNS=9.9.9.9#dns.quad9.net
DNSOverTLS=yes
Примечание
С параметром
DNSOverTLS=yes
DNS-сервер должен тоже поддерживать DNS over TLS, иначе он просто не будет отвечать на запросы.
Другой вариант — использовать DNS over TLS только в том случае, если сервер поддерживает его, указав параметр
DNSOverTLS=opportunistic
. Если используемый DNS-сервер не поддерживает DNS over TLS, systemd-resolved вернётся к обычному незашифрованному DNS.
С помощью
ngrep
можно проверить, работает ли DNS over TLS, поскольку для DNS over TLS всегда используется порт 853 (вместо стандартного 53). Если разрешение доменных имён выполняется через DNS over TLS, команда
ngrep port 53
не выдаст ничего, а команда
ngrep port 853
выведет зашифрованные данные.
Wireshark
позволяет более подробно изучить пакеты запросов и ответов DNS over TLS.
Прослушивание дополнительных интерфейсов
По умолчанию
systemd-resolved
отвечает на DNS-запросы локальных приложений через интерфейс loopback. Чтобы
systemd-resolved
стал отвечать на DNS-запросы через дополнительные интерфейсы или адреса, добавьте параметры
DNSStubListenerExtra
для каждого дополнительного интерфейса в файле
resolved.conf(5)
. Например:
/etc/systemd/resolved.conf.d/additional-listening-interfaces.conf
[Resolve]
DNSStubListenerExtra=192.168.10.10
DNSStubListenerExtra=2001:db8:0:f102::10
DNSStubListenerExtra=192.168.10.11:9953
Совет
Это полезно при использовании
systemd-resolved
в качестве DNS-сервера на
маршрутизаторе
.
mDNS
systemd-resolved
может работать в режиме
multicast DNS
, причём и как распознаватель (resolver), так и как передатчик (responder).
Распознаватель выполняет разрешение
имени хоста
по схеме «
имя_хоста
.local».
mDNS будет работать для конкретного соединения только в том случае, если он включён одновременно и в настройках
systemd-resolved
, и в настройках
сетевого менеджера
для данного соединения.
Поддержка mDNS в
systemd-resolved
включена по умолчанию. Её можно отключить с помощью параметра
MulticastDNS
(смотрите
resolved.conf(5) § OPTIONS
).
Включение поддержки mDNS для конкретного соединения зависит от используемого
сетевого менеджера
:
Для
systemd-networkd
— задайте параметр
MulticastDNS
в разделе
[Network]
в файле нужного соединения. Также может понадобиться указать
Multicast=yes
в разделе
[Link]
. Смотрите
systemd.network(5)
.
Для
NetworkManager
— задайте параметр
mdns
в разделе
[connection]
в файле настроек нужного соединения. Это можно сделать с помощью команды
nmcli connection modify
имя_интерфейса
connection.mdns
{yes|no|resolve}
. Смотрите
nm-settings(5)
.
Примечание
Если в системе установлен
Avahi
,
отключите
или
замаскируйте
юниты
avahi-daemon.service
и
avahi-daemon.socket
, чтобы предотвратить конфликты с
systemd-resolved
.
Если вы планируете использовать mDNS при работающем
межсетевом экране
, не забудьте открыть UDP-порт
5353
.
Совет
Можно задать общие настройки для всех соединений
NetworkManager
. Создайте файл настроек в каталоге
/etc/NetworkManager/conf.d/
и задайте параметр
connection.mdns=2
в разделе
[connection]
. Смотрите
NetworkManager.conf(5) § CONNECTION SECTION
и
[1]
.
LLMNR
Link-Local Multicast Name Resolution
— разработанный Microsoft протокол разрешения
имён хостов
.
LLMNR будет работать для конкретного соединения только в том случае, если он включён одновременно и в глобальных настройках
systemd-resolved
(параметр
LLMNR
в
resolved.conf(5) § OPTIONS
), и в настройках
сетевого менеджера
для данного соединения.
systemd-resolved
по умолчанию работает как LLMNR-передатчик, но
systemd-networkd
и
NetworkManager
[2]
требуют дополнительных настроек, чтобы включить этот режим для соединений.
Для
systemd-networkd
— задайте параметр
LLMNR
в разделе
[Network]
. Смотрите
systemd.network(5) § [NETWORK] SECTION OPTIONS
.
Для
NetworkManager
— задайте параметр
llmnr
в разделе
[connection]
. Смотрите
nm-settings(5) § connection setting
.
Совет
Можно задать общие настройки для всех соединений
NetworkManager
. Создайте файл настроек в каталоге
/etc/NetworkManager/conf.d/
и задайте параметр
connection.llmnr
в разделе
[connection]
. Смотрите
NetworkManager.conf(5) § CONNECTION SECTION
.
Если вы планируете использовать LLMNR при работающем
межсетевом экране
, не забудьте открыть UDP- и TCP-порт
5355
.
Запросы
С помощью утилиты
resolvectl
можно отправлять запросы к DNS-серверам, а также к mDNS- или LLMNR-хостам.
Например, DNS-запрос выглядит следующим образом:
$ resolvectl query archlinux.org
archlinux.org: 2a01:4f8:172:1d86::1
               138.201.81.199

-- Information acquired via protocol DNS in 48.4ms.
-- Data is authenticated: no
Решение проблем
systemd-resolved не ищет в локальном домене
Иногда
systemd-resolved
не может выполнить поиск в локальном домене при передаче ему только имени хоста. При этом возможна ситуация, когда с формальной точки зрения всё в порядке — в соответствующем
.network
-файле
systemd-networkd
присутствуют параметры
UseDomains=yes
или
Domains=[список_доменов]
, в результате чего в файле
resolv.conf
, как и положено, появилась строка
search [список_доменов]
. Запустите
networkctl status
или
resolvectl status
, чтобы убедиться, что домены для поиска в самом деле были обнаружены и собраны.
Возможные решения:
Отключите
LLMNR
, чтобы
systemd-resolved
начал присоединять DNS-суффиксы.
Отредактируйте базу данных
hosts
в файле
/etc/nsswitch.conf
(например, удалите опцию
[!UNAVAIL=return]
после службы
resolve
).
Перейдите на использование полных доменных имён.
Используйте файл
/etc/hosts
для разрешения имён.
Используйте службу
dns
из библиотеки glibc вместо
resolve
из systemd.
systemd-resolved не выполняет разрешение имён без суффикса
Чтобы systemd-resolved выполнял разрешение частичных доменных имён, добавьте параметр
ResolveUnicastSingleLabel=yes
в
/etc/systemd/resolved.conf
.
Важно
Имена, состоящие из одной метки (label), будут направляться на глобальные DNS-сервера, которые вы, вполне вероятно, не контролируете. Это поведение не соответствует стандартам и может создать риски безопасности и приватности. Подробнее смотрите
resolved.conf(5)
.
Судя по всему, это работает только с отключённым LLMNR (
LLMNR=no
).
Если вы используете
systemd-networkd
, то можно использовать в качестве поискового домен, предоставленный DHCP-сервером или IPv6 Router Advertisement. По умолчанию эта возможность отключена; для включения добавьте следующие строки в
.network
-файл сетевого интерфейса:
[DHCPv4]
UseDomains=true

[DHCPv6]
UseDomains=true

[IPv6AcceptRA]
UseDomains=true
Проверить домены для всех интерфейсов можно командой:
$ resolvectl domain
Смотрите также
Francisco Ros о разрешении доменных имён с systemd-resolved
Больше примеров в руководстве
resolvectl(1) § EXAMPLES