Linux restart resolve service

Как отключить systemd-resolve в Linux

В данной статье мы рассмотрим вопрос отключения systemd-resolve в ОС семейства Linux, таких как Ubuntu или Mint.

Отключаем systemd-resolve

Для этого необходимо выполнить следующие команды:

Первая команда отключает автостарт сервиса systemd-resolved, а вторая — прерывает его работу.

Вносим правки в resolv.conf

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

Если этого не сделать, то возможны проблемы в работе и получение различных ошибок, например:

Temporary failure in name resolution

Чтобы исправить это безобразие, сначала удаляем симлинк для конфига:

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

nameserver 8.8.8.8 и nameserver 8.8.4.4 — адреса DNS серверов, к которым будут делаться обращения для разрешения доменных имен.
search example.com domain.local — возможные суффиксы для адресов, в том случае, если не удалось обнаружить адрес в том виде, как он был изначально задан. Т.е. при попытке разрешить доменное имя sysadmin, будут последовательно к нему дописаны указанные выше суффиксы и предпринята попытка разрешить их в виде sysadmin.example.com, а в случае неудачи, то sysadmin.domain.local. Если для вас это не актуально, то данную строчку можно не прописывать вообще.

Вносим правки в NetworkManager.conf (Опционально)

Если вы пользуетесь каким-либо окружением рабочего стола, а не голой консолью, то необходимо еще внести правки в конфиг /etc/NetworkManager/NetworkManager.conf , чтобы и в графической среде у вас все работало как следует. Для этого открываем для редактирования указанный конфиг и вносим в секцию [main] следующую строку:

Целиком, это может выглядеть примерно так:

После того, как вы внесли правки в конфиг и сохранили его, необходимо перезапустить network-manager следующей командой:

Источник

systemd-resolved

systemd-resolved is a systemd service that provides network name resolution to local applications via a D-Bus interface, the resolve NSS service ( nss-resolve(8) ), and a local DNS stub listener on 127.0.0.53 . See systemd-resolved(8) for the usage.

Contents

Installation

systemd-resolved is a part of the systemd package that is installed by default.

Configuration

The resolver can be configured by editing /etc/systemd/resolved.conf and/or drop-in .conf files in /etc/systemd/resolved.conf.d/ . See resolved.conf(5) .

To use systemd-resolved start and enable systemd-resolved.service .

systemd-resolved has four different modes for handling the Domain name resolution (the four modes are described in systemd-resolved(8) § /ETC/RESOLV.CONF ). We will focus here on the two most relevant modes.

1. Using the systemd DNS stub file — the systemd DNS stub file /run/systemd/resolve/stub-resolv.conf contains the local stub 127.0.0.53 as the only DNS server and a list of search domains. This is the recommended mode of operation. The service users are advised to redirect the /etc/resolv.conf file to the local stub DNS resolver file /run/systemd/resolve/stub-resolv.conf managed by systemd-resolved. This propagates the systemd managed configuration to all the clients. This can be done by replacing /etc/resolv.conf with a symbolic link to the systemd stub:
2. Preserving resolv.conf — this mode preserves /etc/resolv.conf and systemd-resolved is simply a client of this file. This mode is less disruptive as /etc/resolv.conf can continue to be managed by other packages.

Setting DNS servers

Automatically

systemd-resolved will work out of the box with a network manager using /etc/resolv.conf . No particular configuration is required since systemd-resolved will be detected by following the /etc/resolv.conf symlink. This is going to be the case with systemd-networkd or NetworkManager.

However, if the DHCP and VPN clients use the resolvconf program to set name servers and search domains (see openresolv#Users for a list of software that use resolvconf), the additional package systemd-resolvconf is needed to provide the /usr/bin/resolvconf symlink.

Manually

In local DNS stub mode, custom DNS server(s) can be set in the resolved.conf(5) file:

. option in resolved.conf(5) , systemd-resolved might use the per-link DNS servers, if any of them set Domains=

. in the per-link configuration.

This option will not affect queries of domain names that match the more specific search domains specified in per-link configuration, they will still be resolved using their respective per-link DNS servers.

For more information on per-link configuration see systemd-networkd#network files.

Fallback

If systemd-resolved does not receive DNS server addresses from the network manager and no DNS servers are configured manually then systemd-resolved falls back to the fallback DNS addresses to ensure that DNS resolution always works.

The addresses can be changed by setting FallbackDNS= in resolved.conf(5) . E.g.:

To disable the fallback DNS functionality set the FallbackDNS option without specifying any addresses:

DNSSEC

DNSSEC validation can be enabled by changing DNSSEC= setting in resolved.conf(5) .

• Set DNSSEC=allow-downgrade to validate DNSSEC only if the upstream DNS server supports it.
• Set DNSSEC=true to always validate DNSSEC, thus breaking DNS resolution with name servers that do not support it. For example:

Test DNSSEC validation by querying a domain with a invalid signature:

Now test a domain with valid signature:

DNS over TLS

DNS over TLS is disabled by default. To enable it change the DNSOverTLS= setting in the [Resolve] section in resolved.conf(5) . To enable validation of your DNS provider’s server certificate, include their hostname in the DNS= setting in the format ip_address#hostname . For example:

ngrep can be used to test if DNS over TLS is working since DNS over TLS always uses port 853 and never port 53. The command ngrep port 53 should produce no output when a hostname is resolved with DNS over TLS and ngrep port 853 should produce encrypted output.

Wireshark can be used for more detailed packet inspection of DNS over TLS queries. It is provided by the wireshark-cli and wireshark-qt packages.

systemd-resolved is capable of working as a multicast DNS resolver and responder.

The resolver provides hostname resolution using a «hostname.local» naming scheme.

mDNS will only be activated for the connection if both the systemd-resolved’s global setting ( MulticastDNS= in resolved.conf(5) ) and the network manager’s per-connection setting is enabled. By default systemd-resolved enables mDNS responder, but both systemd-networkd and NetworkManager[1] do not enable it for connections:

• For systemd-networkd the setting is MulticastDNS= in the [Network] section. You may also have to set Multicast=yes in the [Link] section. See systemd.network(5) .
• For NetworkManager the setting is mdns= in the [connection] section. See nm-settings(5) . You will also need to enable it on each interface you want mDNS to work: systemd-resolve —set-mdns=yes —interface=name .

If you plan to use mDNS and use a firewall, make sure to open UDP port 5353 .

LLMNR

Link-Local Multicast Name Resolution is a hostname resolution protocol created by Microsoft.

LLMNR will only be activated for the connection if both the systemd-resolved’s global setting ( LLMNR= in resolved.conf(5) ) and the network manager’s per-connection setting is enabled. By default systemd-resolved enables LLMNR responder; systemd-networkd and NetworkManager[2] enable it for connections.

• For systemd-networkd the setting is LLMNR= in the [Network] section. See systemd.network(5) .
• For NetworkManager the setting is llmnr= in the [connection] section. See nm-settings(5) .

If you plan to use LLMNR and use a firewall, make sure to open UDP and TCP ports 5355 .

Lookup

To query DNS records, mDNS or LLMNR hosts you can use the resolvectl utility.

For example, to query a DNS record:

Troubleshooting

systemd-resolved not searching the local domain

systemd-resolved may not search the local domain when given just the hostname, even when UseDomains=yes or Domains=[domain-list] is present in the appropriate systemd-networkd’s .network file, and that file produces the expected search [domain-list] in resolv.conf . You can run networkctl status or resolvectl status to check if the search domains are actually being picked up.

• Disable LLMNR to let systemd-resolved immediately continue with appending the DNS suffixes
• Trim /etc/nsswitch.conf ‘s hosts database (e.g., by removing [!UNAVAIL=return] option after resolve service)
• Switch to using fully-qualified domain names
• Use /etc/hosts to resolve hostnames
• Fall back to using glibc’s dns instead of using systemd’s resolve

systemd-resolved does not resolve hostnames without suffix

To make systemd-resolved resolve hostnames that are not fully qualified domain names, add ResolveUnicastSingleLabel=yes to /etc/systemd/resolved.conf .

This only seems to work with LLMR disabled ( LLMR=no ).

If you are using systemd-networkd, you might want the domain supplied by the DHCP server or IPv6 Router Advertisement to be used as a search domain. This is disabled by default, to enable it add to the interface’s .network file:

You can check what systemd-resolved has for each interface with:

Источник

Настройка DNS на Ubuntu Server 18.04 LTS

Стало достаточно традиционным для Linux запускать небольшой локальный DNS-сервер, который ускоряет работу, кешируя ответы на повторяющиеся DNS-запросы. В этом случае в общесистемный /etc/resolv.conf помещается директива nameserver 127.0.0.1 , а ip-адреса внешних DNS-серверов переносятся в настройки локального.

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

При этом файл resolv.conf заменяется символической ссылкой на /run/resolvconf/resolv.conf и программы используют динамически сгенерированный файл. В системе без службы resolvconf.service файл resolv.conf поддерживается вручную или набором скриптов. И эти скрипты могут мешать друг другу при попытках одновременного доступа к файлу.

Всё работало хорошо, пока не появились NetworkManager и Systemd. Система инициализации Systemd имеет свой собственный резолвер systemd-resolved , запущенный по умолчанию и требующий отдельной настройки. А NetworkManager пытается дружить со всеми — с resolvconf , с Systemd , с наиболее распространёнными DNS-резолверами.

Всё это привело к тому, что теперь в одной системе порт 53 может слушать несколько разных резолверов, причём для избежания конфликтов NetworkManager и systemd-resolved используют вместо 127.0.0.1 другие ip-адреса в loopback-сети:

• 127.0.0.1 — dnsmasq или unbound с настройками по умолчанию
• 127.0.1.1 — dnsmasq или unbound , запущенный NetworkManager
• 127.0.0.53 — systemd-resolved , запущенный по умолчанию

Настройка службы systemd-resolved

В Ubuntu Server эта служба уже установлена и запущена сразу после установки операционной системы. Но если это не так, установить ее несложно:

Следующим шагом будет правка файла /etc/nsswitch.conf — находим строку, которая начинается с hosts :

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

Осталось сообщить systemd-resolved ip-адреса DNS-серверов, к которым следует обращаться для резолвинга:

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

В файле /run/systemd/resolve/stub-resolv.conf указан один-единственный сервер 127.0.0.53 :

Кроме того, можно создать символическую ссылку на /run/systemd/resolve/resolv.conf . Этот файл содержит DNS-сервера, полученные от DHCP-сервера и из файла конфигурации /etc/systemd/resolved.conf . В этом случае локальный кеширующий сервер не используется, что замедлит резолвинг.

Как видите, у меня DNS-серверов получилось слишком много, так что последняя запись может быть проигнорирована. Все готово, остается только разрешить запуск службы при загрузке системы, если это еще не было сделано:

Настройка службы resolvconf.service

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

После установки /etc/resolv.conf будет представлять из себя ссылку на /run/resolvconf/resolv.conf .

При этом исходный файл /etc/resolv.conf (который на самом деле ссылка на /run/systemd/resolve/resolv.conf ) будет сохранен как original в директории /etc/resolvconf/resolv.conf.d/ (чтобы восстановить его при удалении службы resolvconf.service ). В этой же директории есть есть еще три файла — base , head и tail — которые позволяют вручную добавить записи в динамически формируемый /run/resolvconf/resolv.conf .

Теперь добавим пару записей в файл tail (сервера OpenDNS):

Перезагрузим службу и посмотрим сформированный /run/resolvconf/resolv.conf :

Первая запись — это резолвер systemd-resolved , а две другие записи были добавлены в конец resolv.conf из файла tail . Благодаря тому, что первая запись это 127.0.0.53 — резолвинг будет работать быстро, потому что systemd-resolved кеширует ответы DNS-серверов.

Но если мы остановим службу systemd-resolved , резолвинг все равно будет работать, используя сервера 208.67.222.222 и 208.67.220.220 — хотя и гораздо медленнее.

Используем только resolv.conf

Так делать не рекомендуется, потому что резолвинг будет работать медленно, но рассмотрим и этот вариант для полноты картины. Первым делом изменим имя файла /etc/resolv.conf на /etc/resolv.conf.back , а потом создадим свой resolv.conf :

Для Ubuntu Desktop запретим вездесущему NetworkManager вмешиваться в процесс распознавания доменных имен:

Остановим службы resolvconf.service и systemd-resolved.service :

Проверим, как теперь работает распознавание доменных имен:

Источник