Systemd resolved что это

Unbound и systemd-resolved. Вообще для чего нужен локальный DNS резолвер в линуксе и особенно в убунте.

Немного нубский вопрос — но зачем нужен локальнй резолвер в линуксе? Разве все приложения когда резолвят адрес обращаются вначале к 127.0.0.53:53 Или тот же самый браузер сразу лезет на указанный в сетевых настройках адрес?

Как работает если используется SNAT или MASQURADE

Также как лучше и разумнее всего поменять резолвер если используется Unbound.

Или это все появилось только в SystemD и до этого резолвилось все по другому — файл host и если нет то dns который указан в сети? Или это networkmanager виноват?

glorsh66
24.03.22 19:49:17 MSK

Локально? Для кеширования.
Я пользуюсь kresd, работает хорошо, но у него есть и свои заморочки.

imul ★★★★★
( 24.03.22 21:27:47 MSK )

Часть политики централизации же. Ну и удобство как-никак. Я лично всегда выпиливаю systemd-resolved. Тут выбор не большой, либо ты сам занимаешься dns, либо доверяешься кому-то.

Anoxemian ★★★★★
( 24.03.22 21:41:59 MSK )

systemd-resolved правильнее всего выключать штатным для него способом, выключая DNSSTubListener создав в /etc/systemd/resolved.conf.d/ файлик, например, unbound.conf c содержимым

[Resolve] DNS=127.0.0.1 DNSStubListener=no

сделав новый симлинк на resolv.conf

sudo mv /etc/resolv.conf /etc/resolv.conf.backup sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

и перезапустив systemd-resolved

P.S. и да, использовать надо IMHO не локальный резолвер на каждом тазике, а централизованный для всей сети (домашней, офисной, etc) И не unbound, а blocky или даже adguardHome. последний умеет в DoH/DoT/DNSCrypt апстримы, умеет резолвить (не)нужные рекламные хосты и трекеры в блэкхол или в 127.0.0.1, что резко сокращает количество рекламы. Unbound тоже умеет, в принципе, с изолентингом, костылингом, скриптингом и зачем?

mgdz
( 25.03.22 06:37:23 MSK )
Ответ на: комментарий от mgdz 25.03.22 06:37:23 MSK

пишитинг более понятинг

Shushundr ★★★
( 25.03.22 08:02:15 MSK )

Локальный резолвер нужен для того, чтобы снизить обращение к DNS-серверам, сэкономить время (не ждать, пока от DNS-сервера поступит ответ) и количество обращений к DNS-серверам в целом.

В Ubuntu это systemd-resloved

Настроить DNS в systemd-resloved можно через этот файл (необходимо будет создать самому):

vodka@vodka-PC:/tmp/firefox_autoupdate$ cat /etc/systemd/resolved.conf.d/resolved.conf DNS=192.168.1.1 8.8.8.8 FallbackDNS=8.8.8.8 1.1.1.1 #Domains= #DNSSEC=no #DNSOverTLS=no MulticastDNS=yes LLMNR=yes Cache=no-negative #CacheFromLocalhost=no DNSStubListener=yes #DNSStubListenerExtra= ReadEtcHosts=yes #ResolveUnicastSingleLabel=no

Для корректной работы необходимо, чтобы resolv.conf смотрел вот на этот файл:

vodka@vodka-PC:/tmp/firefox_autoupdate$ ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 37 мар 21 13:19 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

rm /etc/resolv.conf ls -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Далее включить systemd-resolved:

systemctl enable --now systemd-resolved

Только в этом случае будет работать systemd-resolved. Содержимое resolv.conf должен выглядеть вот так (оно само формируется с помощью systemd-resolved):

vodka@vodka-PC:/tmp/firefox_autoupdate$ ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 37 мар 21 13:19 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf vodka@vodka-PC:/tmp/firefox_autoupdate$ cat /run/systemd/resolve/stub-resolv.conf nameserver 127.0.0.53 options edns0 trust-ad search .

Собственно, видно, что используется локальный DNS-сервер (nameserver 127.0.0.53)

vodka@vodka-PC:/tmp/firefox_autoupdate$ systemd-resolve --statistics DNSSEC supported by current servers: no Transactions Current Transactions: 0 Total Transactions: 19442 Cache Current Cache Size: 146 Cache Hits: 9376 Cache Misses: 10136 DNSSEC Verdicts Secure: 0 Insecure: 0 Bogus: 0 Indeterminate: 0

Ну и другие опции команды systemd-resolved или resolvedctl

Также обратите внимание, что у браузеров тоже есть свой локальный DNS-кеш. Можно его выключить при наличии своего локального DNS-сервера в случае systemd-resloved: https://www.reddit.com/r/firefox/comments/oia26o/how_to_disable_dns_cache_fully/

iljuase ★★★
( 26.03.22 15:33:50 MSK )
Последнее исправление: iljuase 26.03.22 15:35:44 MSK (всего исправлений: 2)

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

Состояние перевода: На этой странице представлен перевод статьи systemd-resolved. Дата последней синхронизации: 11 июля 2021. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

systemd-resolved — служба systemd, выполняющая разрешение сетевых имён для локальных приложений посредством D-Bus, NSS-службы resolve (см. nss-resolve(8) ) или локальной слушающей DNS-заглушки на адресе 127.0.0.53 . Подробнее об использовании см. systemd-resolved(8) .

Установка

systemd-resolved входит в пакет systemd , который установлен по умолчанию.

Настройка

Настройки распознавателя можно изменить в файле /etc/systemd/resolved.conf и/или с помощью drop-in-файлов с суффиксом .conf в каталоге /etc/systemd/resolved.conf.d/ . См. resolved.conf(5) .

Для запуска systemd-resolved запустите и включите службу systemd-resolved.service .

Совет: Чтобы лучше понимать контекст выборов и переключателей, включите для systemd-resolved сохранение подробной отладочной информации по инструкции в статье systemd#Диагностика службы.

DNS

systemd-resolved может выполнять разрешение доменных имён четырьмя различными способами. Все четыре режима работы подробно описаны в руководстве systemd-resolved(8) § /ETC/RESOLV.CONF . Наиболее часто используются следующие два:

рекомендуемый

# ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

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

Выбор DNS-серверов

Совет: Узнать, какие серверы systemd-resolved использует в данный момент, можно командой resolvectl status .

Автоматически

systemd-resolved работает «из коробки» с сетевыми менеджерами, использующими файл /etc/resolv.conf . Никаких дополнительных настроек не требуется, поскольку systemd-resolved будет автоматически обнаружен при переходе по символической ссылке /etc/resolv.conf . Во всяком случае, это работает для systemd-networkd и NetworkManager.

Тем не менее, если какой-то 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 .

Вручную

В режиме локальной DNS-заглушки можно назначить произвольные 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 (без фильтрации и DNSSEC) и 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 настраивается параметром 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 sigfail.verteiltesysteme.net

sigfail.verteiltesysteme.net: resolve call failed: DNSSEC validation failed: invalid

Затем проверьте домен, подпись которого в порядке:

$ resolvectl query sigok.verteiltesysteme.net

sigok.verteiltesysteme.net: 134.91.78.139 -- Information acquired via protocol DNS in 266.3ms. -- Data is authenticated: yes

DNS over TLS

Важно: В systemd до версии 245.2-2 systemd-resolved проверяет сертификат DNS-сервера только в том случае, если он был выдан для IP-адреса сервера (что встречается довольно редко). Сертификаты без IP-адреса не проверяются, что открывает возможность для атаки «человек-посередине». См. systemd issue 9397.

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

Примечание: DNS-сервер должен тоже поддерживать DNS over TLS, иначе он просто не будет отвечать на запросы.

С помощью ngrep можно проверить, работает ли DNS over TLS. В этом режиме для DNS-запросов используется порт 853 (вместо стандартного 53). По этой причине при разрешении имени с DoT команда ngrep port 53 не выдаст ничего, а команда ngrep port 853 выведет зашифрованные данные.

Wireshark позволяет более подробно изучить пакеты запросов и ответов DNS over TLS. Установить Wireshark можно с пакетами wireshark-cli и wireshark-qt .

mDNS

systemd-resolved может работать в режиме multicast DNS, причём и как распознаватель (resolver), так и как передатчик (responder).

Распознаватель выполняет разрешение имени хоста по схеме «имя_хоста.local»

mDNS будет работать для конкретного соединения только в том случае, если он включён одновременно и в глобальных настройках systemd-resolved (параметр MulticastDNS= в resolved.conf(5) ), и в настройках сетевого менеджера для данного соединения. systemd-resolved по умолчанию работает как mDNS-передатчик, но systemd-networkd и NetworkManager [1] требуют дополнительных настроек, чтобы включить этот режим для соединений:

Для systemd-networkd — задайте параметр MulticastDNS= в разделе [Network] , а также Multicast=yes в разделе [Link] . См. systemd.network(5) .
Для NetworkManager — задайте параметр mdns= в разделе [connection] . См. nm-settings(5) . Также необходимо включить режим mDNS для каждого сетевого интерфейса, на котором он будет использоваться: systemd-resolve —set-mdns=yes —interface=имя_интерфейса .

Примечание: Если в системе установлен Avahi, отключите или замаскируйте службы avahi-daemon.service и avahi-daemon.socket , чтобы предотвратить конфликты с systemd-resolved.

Совет: Можно задать общие настройки для всех соединений NetworkManager. Создайте файл настроек в каталоге /etc/NetworkManager/conf.d/ и задайте параметр connection.mdns= в разделе [connection] . См. NetworkManager.conf(5) .

Если вы планируете использовать mDNS при работающем межсетевом экране, не забудьте открыть UDP-порт 5353 .

LLMNR

LLMNR будет работать для конкретного соединения только в том случае, если он включён одновременно и в глобальных настройках systemd-resolved (параметр LLMNR= в resolved.conf(5) ), и в настройках сетевого менеджера для данного соединения. systemd-resolved по умолчанию работает как LLMNR-передатчик, но systemd-networkd и NetworkManager [2] требуют дополнительных настроек, чтобы включить этот режим для соединений:

Для systemd-networkd — задайте параметр LLMNR= в разделе [Network] . См. systemd.network(5) .
Для NetworkManager — задайте параметр llmnr= в разделе [connection] . См. nm-settings(5) .

Совет: Можно задать общие настройки для всех соединений NetworkManager. Создайте файл настроек в каталоге /etc/NetworkManager/conf.d/ и задайте параметр connection.llmnr= в разделе [connection] . См. NetworkManager.conf(5) .

Если вы планируете использовать 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 [IPv6AcceptRA] UseDomains=yes

Проверить домены для всех интерфейсов можно командой:

$ resolvectl domain

Смотрите также

Francisco Ros о разрешении доменных имён с systemd-resolved
Больше примеров в руководстве resolvectl(1) § EXAMPLES

Чиним резолвинг адресов в VPN-локалке (openconnect) для docker и systemd-resolved

Для подключения к корпоративной сети у нас используется CiscoAnyConnect, работает хорошо, но не с докером. Как только докер пытается приподнять свою сеть, утилитка тут же отрубает VPN и переподключает. От этого докер себя плохо чувствует. Поэтому я решил использовать обычный линуксовый openconnect соместно с NetworkManager.

systemd-resolved

Поставил пакеты network-manager-openconnect network-manager-openconnect-gnome
Настроил соединение и оно даже подключилось. Проблема первая, каждый раз когда я подключался снова, он забывал имя пользователя, что раздражает. Я нашел решение и создал
баг. Решение простое, с консоли задаем свое имя в особом виде nmcli con mod prgcvp vpn.secrets ‘form:main:username=yourName’,’save_passwords=yes’
После чего оно будет запомнено. Да, галочку «запомнить пароль» я ставил и пароль он даже запомнил, но вот в тексте галочки про имя пользователя ничего не сказано, так что он честно его забыл 🙂 Напомню, что настройки менеджера лежат в /etc/NetworkManager/system-connections/.

И если параметры знаешь, то можно и руками отредактировать нужное соединение.

Подключаться стало удобно и возникла вторая проблема, имена ресурсов в VPN сети не разрешаются в адреса DNS сервером. Сервер есть, все настройки на месте, но nslookup someserver.local выдает ошибку, а nslookup someserver.local somednsIP выдет правильный ответ. Странно, подумал я, как так, сервер есть, отвечает, а если его конкретно не указать, ошибка? Ответ оказался прост. Когда systemd-resolved пытается найти адрес сервера по имени, он выступает фасадом для других DNS серверов. Делается это так, ссылка /etc/resolv.conf может указывать на несколько мест:

/run/systemd/resolve/stub-resolv.conf это опция по умолчанию и этот файл будет содержать примерно такое
nameserver 127.0.0.53
options edns0 trust-ad
search somedomain.local
/run/systemd/resolve/resolv.conf это можно использовать если функционал systemd-resolved чем то не устроил когда он прикидывается DNS сервером 127.0.0.53. В итоге это не пригодилось, так для информации пишу.

Саму ссылку /etc/resolv.conf вы можете сами настроить что бы смотрела в любое из мест.
Так вот, дело в том, что openconnect при подключении к VPN получает таблицу route, DNS сервера, а так же search domain и этот домен от VPN сервера приходил неверный (так неправильно настроен у нас). От сервера приходило somedomain.local, а надо было просто local что бы somesrver.local был распознан.

Когда systemd-resolved прикинулся локальным DNS сервером и через /etc/resolv.conf всех отправил к себе за разрешением имен, логика его работы такова. Для каждого коннекта, которые можно посмотреть командой nmcli connection show (это те коннекты, которые знает NetworkManager) systemd-resolved помнит DNS сервера, которые получил по DHCP. Это можно посмотреть командой:

resolvectl dns Global: Link 6 (docker0): Link 5 (vpn0): 999.999.999.999 999.999.999.999 Link 3 (wlp4s0): 192.168.3.8 Link 2 (enp5s0f2):

Когда в 127.0.0.53 приходит запрос на разрешение имени, systemd-resolved смотрит search domain у каждого из коннектов (эти домены он при подключении от DHCP получил тоже). Домены можно посмотреть командой:

resolvectl domain Global: Link 6 (docker0): Link 5 (vpn0): somedomain.local Link 3 (wlp4s0): ~. Link 2 (enp5s0f2):

Далее имя хоста проверяется на частичное совпадение с теми доменами, которые прикреплены к коннектам и самое длинное совпадение и определяет какой конкретно DNS сервер вызвать. Либо все идет в DNS сервер где search domain «~.»

От сервера компании мне приходил неверный search domain (somedomain.local) для VPN коннекта и потому когда я пытался разрешить адрес someserver.local, systemd-resolved их не мог найти, так как предполагал, что DNS сервера, полученные из этого соединения нужны что бы распознавать имена someserver.somedomain.local. Поправил я это подменив search domain в NetworkManager командой
nmcli connection modify yourConnectionName ipv4.dns-search «local»
Доменов может быть несколько через пробел. В итоге все заработало.
Помимо этого я удалил пакет avahi-daemon, так как службы bonjur, которые обслуживает этот демон по умолчанию тоже резолвятся на домене local, а в нашей сетке именно это имя используется для локальной сети и будут конфликты.

docker

Теперь в хост системе работает резолвинг адресов, но при запуске докера резолвинг локальных адресов в VPN может не работать по прежнему. И тут есть несколько вариантов.

Контейнер запущен с network_mode: host в таком случае будет использоваться для резольвинга то, что лежит в /run/systemd/resolve/resolv.conf и там у меня первый же днс сервер выбирается для резольва local и он для этого не подходит. Итог, не работает. Зато все сервисы хост машины видно из контейнера, что еще и неправильно.

Контейнер запущен с network_mode: bridge с созданием отдельной сети. В таком случае сервисы хоста будет не видно, помимо этого будет использован все тот же не работающий у меня /run/systemd/resolve/resolv.conf

Контейнер запущен без настроек сети и использует дефолтный bridge, созданный докером при инсталляции (docker0). В этом случае используется для резольва имен внутренний докеровский DNS, который судя по всему нормально взаимодействует с systemd-resolved и все резолвит как надо. В /etc/resolv.conf будет такое:

bash-5.0# cat /etc/resolv.conf search local nameserver 127.0.0.11 options ndots:0

Если надо показать сервисы хост машины для доступа из контейнера, то просто запускаем сервисы слушать на docker0 IP и получаем доступ.

ifconfig|grep -n1 docker0 27- 28:docker0: flags=4099 mtu 1500 29- inet 192.168.32.1 netmask 255.255.240.0 broadcast 192.168.47.255

Не забываем открыть порты, например у меня ufw зарезал 8080 и пришлось открывать.
Было бы отлично если бы docker просто использовал systemd-resolved dns stub как в последнем описанном варианте всегда. Но к сожалению это не так. В версии systemd-resolved 248, которая только вышла и в дистрах ее нет в документации есть параметр DNSStubListenerExtra, который может задать адрес где слушать для stub. Подробности тут.

В итоге можно будет указать адрес где слушать не захардкоженный 127.0.0.53, а доступный изнутри докера и все будет работать, но пока нет.

Есть другое решение, когда контейнер пойдет на порт 53 мы будем перебрасывать его запросы в стаб systemd с помощью чего то вроде
socat UDP-LISTEN:53,fork,reuseaddr,bind=yourInterfaceIP UDP:127.0.0.53:53
Соответственно, этот DNS можно указать докеру при старте и весь функционал systemd будет работать. Но не стал это использовать.

В итоге мы получаем работающий VPN на хосте, который резолвит имена в локальной сети, работающий докер, который может резолвить эти адреса как родные.

[Work] Настройка systemd-resolved

work

Привет, %username% ! Очень давно я писал о том, как я настраивал dnsmasq для настройки локальной зоны. Сейчас мы настроим systemd-resolved как локальный кэширующий резолвер.

Его настройку я рассматриваю только потому, что systemd-resolved есть в системе (в нормальной свежей системе с systemd).

Для начала установим модуль nss-resolve (библиотека libnss_resolve.so из пакета libnss-resolve ) для механизма Name Service Switch ( NSS ), который будет вызывать службу systemd-resolved для разрешения имён:

sudo apt install libnss-resolve

Установка данного модуля приведет к изменению в файле /etc/nsswitch.conf – строка hosts: files dns будет автоматически заменена на следующую:

. hosts: files resolve [!UNAVAIL=return] dns .

Теперь приступим к настройке самого systemd-resolved . Содержимое файла /etc/systemd/resolved.conf приводим к следующему виду:

# This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # # Entries in this file show the compile time defaults. # You can change settings by editing this file. # Defaults can be restored by simply deleting this file. # # See resolved.conf(5) for details  [Resolve] DNS=10.20.213.10 10.20.213.20 FallbackDNS=1.1.1.1 8.8.8.8 8.8.4.4 Domains=jtprog.ru jtprog.local LLMNR=yes #MulticastDNS=no #DNSSEC=no #DNSOverTLS=no Cache=no-negative #DNSStubListener=yes ReadEtcHosts=yes

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

sudo ln -svi /run/systemd/resolve/resolv.conf /etc/resolv.conf ln: replace '/etc/resolv.conf'? y '/etc/resolv.conf' -> '/run/systemd/resolve/resolv.conf'

Теперь запускаем службу и включаем автозапуск:

systemctl enable systemd-resolved systemctl restart systemd-resolved systemctl status systemd-resolved

На этом всё! Profit!

Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат, а так же подписывайся на канал.

systemd
resolved
systemd-resolved