Ubuntu systemd resolved настройка
Обновлено: 05.07.2024
Скорость загрузки вашей операционной системы - это очень важный момент в работе компьютера. Никому не хочется смотреть на заставку загрузки по несколько минут. Чем быстрее загрузится система и будет готова к работе, тем лучше.
Но порой система инициализации выполняет много лишних задач во время загрузки, иногда некоторые сервисы ожидают загрузки других и завершаются только по таймауту через некоторое время. В таких случаях система может загружаться до нескольких минут. В этой статье мы рассмотрим как ускорить загрузку Linux, что нужно для этого настроить, что удалить. А также немного поговорим о процессе загрузки. Мы сосредоточимся на системе инициализации systemd.
Как проходит загрузка Linux
Во всех подробностях процесс загрузки Linux описан в отдельной статье, здесь же мы рассмотрим только то, что будет касаться ускорения.
На то как BIOS тестирует устройства и запускает загрузчик мы повлиять не можем. Работу загрузчика тоже ускорить не получится, можно только убрать ожидание выбора пункта меню.
Но самое интересное начинается дальше. Перед тем как начать загрузку системы ядро выполняет несколько проверок, загружает модули и так далее. Не все проверки нужно выполнять и не все модули нам нужны.
После того как ядро передало управление системе инициализации, начинается монтирование дисков. Это тоже отнимает время, лучше не использовать виртуальные разделы дисков, например, raid или lvm, да и вообще, чем меньше разделов - тем лучше. Идеальный вариант - только корневой раздел, тогда скорость загрузки linux будет максимальной. Но это очень невыгодный в плане удобства вариант, поэтому найдите золотую серединку. Перед тем как примонтировать каждый диск, система инициализации пытается проверить файловую систему на ошибки, это тоже замедляет загрузку.
Загрузка сервисов отнимает больше всего времени и больше всего работы придется проделать здесь, определить какие сервисы не нужны и отключить их также скрыть те сервисы, которые отключить нельзя. Чтобы понять что именно отключать нам нужно знать сколько времени занимает загрузка каждого сервиса. Давайте рассмотрим анализ скорости загрузки systemd.
Анализ загрузки Systemd
Анализ скорости загрузки системы важен не только в самом процессе оптимизации, но и для того, чтобы оценить насколько эта оптимизация удалась. Перед и после оптимизации нужно замерять время загрузки, чтобы понять чего мы смогли добиться.
Давайте посмотрим насколько быстро грузится наша система сейчас:
Да, здесь 17 секунд, не так уж плохо, но будет еще лучше после завершения ускорения загрузки. На загрузку ядра уходит 5.405, а на все остальные сервисы 11.611. Чтобы понять какие именно сервисы замедляют систему нам нужна более подробная информация, мы можем ее получить с помощью параметра blame:
У нас есть список сервисов, которые загружаются дольше всего, но этот список ни о чем нам не говорит, потому что в Systemd параллельная загрузка сервисов. Если бы во время загрузки была какая-нибудь проблема, мы бы ее увидели, но проблем здесь нет. Нам нужен более детализованный график с указанием не только времени загрузки сервиса, но и с отображением параллельных загрузок и мы можем его получить командой:
systemd-analyze plot > graph.svf
Утилита сгенерирует svf файл с графиком, откройте его в браузере:
Вот теперь у нас есть вся информация, чтобы оптимизировать систему. Здесь отображается не только время загрузки каждого сервиса, но также время когда он начал загружаться и когда завершил. Дальше начнем ускорение загрузки Linux.
Ускорение загрузки Linux
Начнем мы с оптимизации ядра 5 секунд, это не так много, но можно же еще улучшить. Мы не будем пересобирать ядро, хотя и это дало бы больший эффект, мы просто настроим его работу с помощью параметров загрузки.
Настраивать Grub будем правильно. Параметры загрузки ядра находятся в файле /etc/default/grub, а именно в строчке GRUB_CMDLINE_LINUX_DEFAULT. Откройте этот файл:
Теперь приводим интересующую нас строчку к такому состоянию:
GRUB_CMDLINE_LINUX_DEFAULT="quiet rootfstype=ext4 libahci.ignore_sss=1 raid=noautodetect selinux=0 plymouth.enable=0 lpj=12053560"
Разберем подробнее за что отвечает каждый параметр:
- quiet - вывод, это долго, поэтому говорим ядру что на экран нужно выводить минимум информации
- rootfstype=ext4 - указываем в какую файловую систему отформатирован корень. У меня ext4.
- libahci.ignore_sss=1 - Ignore staggered spinup flag, ускоряет загрузку жестких дисков
- raid=noautodetect - raid я не использую, думаю вы тоже поэтому отключаем.
- selinux=0 - система полномочий selinux на домашней машине тоже ни к чему, без нее будет быстрее.
- plymouth.enable=0 - заставка plymouth тоже занимает много времени, поэтому убираем заставку
- lpj=12053560 - позволяет задать константу loops_per_jiffy, что позволит ядру не вычислять ее каждый раз и сэкономит до 250 миллисекунд. Это значение индивидуально для каждого компьютера.
Чтобы узнать значение последнего параметра выполните:
dmesg | grep 'lpj='
Нас будет интересовать значение lpj=, укажите его в своем конфигурационном файле.
Также для указания корневого раздела желательно не использовать всякие там UUID, быстрее будет если написать прямо. Для того чтобы конфигуратор grub не использовал grub добавьте в тот же файл строчку:
Сохраните файл и обновим конфигурацию grub:
Проверяем, действительно ли установлены нужные опции:
Да, все правильно, перезагружаем компьютер, и смотрим что вышло:
Почти на одну секунду быстрее, и то хорошо. Возможно, у вас эффект будет намного лучше. Теперь идем разбираться с сервисами.
Настройка системы
Во-первых SELinux отключен не полностью. Для полного отключения добавляем строку в файл /etc/selinux/config:
sudo vi /etc/selinux/config
Во-вторых, проверка файловых систем тоже может занять некоторое время. Оставляем проверку на ошибки только для корня. Для этого откройте файл /etc/fstab и приведите строчку для корня к такому виду:
/dev/sda3 / ext4 defaults 1 1
Последний параметр отвечает за проверку, 1 - проверять, 0 - не проверять. Установите для всех других разделов 0. К тому же boot раздел лучше монтировать по требованию. Для этого изменяем его запись:
/dev/sda1 /boot ext4 noauto,comment=systemd.automount 1 0
Затем давайте перенесем папку /tmp в оперативную память, чтобы уменьшить количество операций на жестком диске:
tmpfs /tmp tmpfs defaults 0 0
Ускорение загрузки Linux отключением сервисов
Вот мы и добрались к сервисам. Оптимизация сервисов заключается в том, чтобы отключить лишнее, а также использовать только возможности, встроенные в systemd, так будет быстрее. Сначала перенесем всю функциональность на systemd.
Первым отключим rsyslog. В systemd используется свой механизм записи логов journald, поэтому вести еще один не нужно. Для отключения выполните:
sudo systemctl disable rsyslog
$ sudo systemctl mask rsyslog
Опция mask позволяет спрятать юнит, система будет думать что его не существует и не сможет загрузить. Восстановить такой юнит можно командой systemctl unmask.
В systemd реализована своя служба настройки сети - networkd, поэтому необязательно использовать NetworkManager. Работа со встроенной службой будет намного быстрее. Здесь нужно заметить, что если вы используете wifi и не хотите настраивать его вручную, через консоль, то отключать NetworkManager не стоит.
Отключаем NetworkManager и включаем networkd:
sudo systemctl disable NetworkManager
sudo systemctl enable systemd-networkd
Службу networking тоже можно отключить, если не используете:
sudo systemctl disable networking
Включаем resolved, который отвечает за настройку DNS серверов:
sudo systemctl enable systemd-resolved
sudo systemctl start systemd-resolved
Даем символическую ссылку на файл /etc/resolv.conf
sudo rm /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
Осталось настроить динамическое получение ip адреса при загрузке:
[Match]
Name=enp*
[Network]
DHCP=yes
enp0* значит, что сеть нужно подымать только для устройств, имена которых начинаются на enp0. Готово, сеть настроена.
В systemd есть свое решение для выполнения задач по расписанию, поэтому cron можно не использовать:
sudo systemctl disable cron
С заменой разобрались, перейдем к удалению лишнего. Отключаем фаервол, на домашней машине, за маршрутизатором он не нужен:
sudo systemctl disable ufw
$ sudo systemctl mask ufw
Отключаем apport (служба отчетов об ошибках):
sudo systemctl disable apport
Я не использую ppp и мобильные соединения, поэтому и эти сервисы можно отключить.
sudo systemctl disable pppd-dns
sudo systemctl mask pppd-dns
sudo systemctl disable ModemManager
sudo systemctl mask ModemManager
Если вы не используете Avahi, его тоже можно отключить:
sudo systemctl disable avahi-daemon
Систему AppArmor тоже можно отключить:
sudo systemctl disable apparmor
Также если у вас загружаются такие программы, как postfix (почтовый сервер), apache (веб-сервер), mysql (сервер баз данных) лучше их тоже убрать из автозагрузки и запускать потом вручную.
Перезагружаемся и проверяем скорость загрузки:
У меня скорость загрузки linux выросла на пять секунд. Но это нормально, учитывая, что используется VirtualBox, на реальной машине можно получить и больше. А самая лучшая оптимизация - купить SSD, там можно достичь даже скорости загрузки до двух-трех секунд.
Выводы
Вот и все, в этой статье мы рассмотрели как ускорить загрузку Linux. Если у вас долго грузится Linux вы уже знаете что нужно делать. Если вы знаете другие способы ускорить загрузку Linux, напишите в комментариях!
Стало достаточно традиционным для 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 вмешиваться в процесс распознавания доменных имен:
systemd-resolved — служба systemd, выполняющая разрешение сетевых имён для локальных приложений посредством D-Bus, NSS-службы resolve (см. nss-resolve(8) ) или локальной слушающей DNS-заглушки на адресе 127.0.0.53 . Подробнее об использовании см. systemd-resolved(8) .
Contents
Установка
systemd-resolved входит в пакет systemd , который установлен по умолчанию.
Настройка
Настройки распознавателя можно изменить в файле /etc/systemd/resolved.conf и/или с помощью drop-in-файлов с суффиксом .conf в каталоге /etc/systemd/resolved.conf.d/ . См. resolved.conf(5) .
Для запуска systemd-resolved запустите и включите службу systemd-resolved.service .
- С файлом DNS-заглушки systemd — файл /run/systemd/resolve/stub-resolv.conf содержит указание использовать локальную заглушку (local stub) на адресе 127.0.0.53 в качестве единственного DNS-сервера, а также список доменов для поиска. Это рекомендуемый режим работы. Файл /etc/resolv.conf стоит заменить символической ссылкой на файл заглушки, чтобы все процессы использовали последний при разрешения имён:
- С файлом resolv.conf — systemd-resolved работает с файлом /etc/resolv.conf как обычный клиент. Этот режим менее разрушителен, поскольку другие программы по-прежнему смогут использовать /etc/resolv.conf .
Выбор DNS-серверов
Совет: Узнать, какие серверы systemd-resolved использует в данный момент, можно командой resolvectl status .Автоматически
systemd-resolved работает "из коробки" с сетевыми менеджерами, использующими файл /etc/resolv.conf . Никаких дополнительных настроек не требуется, поскольку systemd-resolved будет автоматически обнаружен при переходе по символической ссылке /etc/resolv.conf . Во всяком случае, это работает для systemd-networkd и NetworkManager.
Вручную
В режиме локальной DNS-заглушки можно назначить произвольные DNS-серверы, указав их в файле resolved.conf(5) :
. , то systemd-resolved может использовать DNS-серверы из настроек отдельных сетевых интерфейсов, если параметр Domains=
Резерв
Если systemd-resolved не получает адреса DNS-серверов от сетевого менеджера и никакие сервера не были настроены вручную, то он использует специальные зарезервированные DNS-адреса. Таким образом, разрешение доменных имён работает всегда.
Примечание: В качестве резервных используются следующие сервера: Cloudflare, Quad9 (без фильтрации и DNSSEC) и Google; сервера и их порядок определены в файле PKGBUILD пакета systemd.Изменить адреса можно с помощью параметра FallbackDNS= в файле resolved.conf(5) , например:
Чтобы полностью отключить функциональность резервных DNS-серверов, задайте параметр FallbackDNS без указания адреса:
DNSSEC
Проверка DNSSEC настраивается параметром DNSSEC= в файле resolved.conf(5) .
- DNSSEC=allow-downgrade — проверка выполняется только в том случае, если опрашиваемый сервер её поддерживает.
- DNSSEC=true — проверка выполняется всегда; если сервер не поддерживает DNSSEC, то разрешение доменных имён работать не будет. Пример:
- Если ваш DNS-сервер не поддерживает DNSSEC и вы испытываете проблемы в стандартном (используется по умолчанию) allow-downgrade-режиме (см. systemd issue 10579), попробуйте полностью отключить DNSSEC в systemd-resolved параметром DNSSEC=false .
- systemd-resolved может отключить DNSSEC после нескольких неудачных попыток выполнить проверку. Если задано значение DNSSEC=true , то разрешение имён вообще перестанет работать. См. systemd issue 9867.
Проверьте, работает ли DNSSEC, отправив запрос к домену с неправильной подписью:
Затем проверьте домен, подпись которого в порядке:
DNS over TLS
Важно: В systemd до версии 245.2-2 systemd-resolved проверяет сертификат DNS-сервера только в том случае, если он был выдан для IP-адреса сервера (что встречается довольно редко). Сертификаты без IP-адреса не проверяются, что открывает возможность для атаки "человек-посередине". См. systemd issue 9397. Примечание: DNS-сервер должен тоже поддерживать DNS over TLS, иначе он просто не будет отвечать на запросы.С помощью ngrep можно проверить, работает ли DNS over TLS. В этом режиме для DNS-запросов используется порт 853 (вместо стандартного 53). По этой причине при разрешении имени с DoT команда ngrep port 53 не выдаст ничего, а команда ngrep port 853 выведет зашифрованные данные.
systemd-resolved может работать в режиме multicast DNS, причём и как распознаватель (resolver), так и как передатчик (responder).
Распознаватель выполняет разрешение имени хоста по схеме "имя_хоста.local"
mDNS будет работать для конкретного соединения только в том случае, если он включён одновременно и в глобальных настройках systemd-resolved (параметр MulticastDNS= в resolved.conf(5) ), и в настройках сетевого менеджера для данного соединения. systemd-resolved по умолчанию работает как mDNS-передатчик, но systemd-networkd и NetworkManager [1] требуют дополнительных настроек, чтобы включить этот режим для соединений:
Примечание: Если в системе установлен 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] требуют дополнительных настроек, чтобы включить этот режим для соединений:
Совет: Можно задать общие настройки для всех соединений NetworkManager. Создайте файл настроек в каталоге /etc/NetworkManager/conf.d/ и задайте параметр connection.llmnr= в разделе [connection] . См. NetworkManager.conf(5) .Если вы планируете использовать LLMNR при работающем межсетевом экране, не забудьте открыть UDP- и TCP-порт 5355 .
Запросы
С помощью утилиты resolvectl можно отправлять запросы к DNS-серверам, а также к mDNS- или LLMNR-хостам.
Например, DNS-запрос выглядит следующим образом:
Решение проблем
systemd-resolved не ищет в локальном домене
- Отключите 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) .Судя по всему, это работает только с отключённым LLMR ( LLMR=no ).
Для работы с systemd-resolved вам понадобится демон systemd-resolved. В Ubuntu он уже входит в пакет systemd (в 16.04 точно), а вот в Centos 7 его придется доустановить:
yum install systemd-resolved
Так же необходимо убедиться в наличии библиотеки libnss_resolve.so - без нее приложения не смогут связываться с резолвером.
В Centos эта библиотека входит в пакет systemd-resolved, а в ubuntu придется выполнить:
apt install libnss-resolve
Следующим шагом будет правка файла /etc/nsswitch.conf. Находим строчку, начинающуюся с "hosts:" и приводим к виду:
hosts: files resolve
Поясним. Эта строка отвечает за последовательность обращений приложения к системным компонентам с целью резолвинга интересующего приложение имени. В данном случае сначала программа заглянет в файл /etc/hosts и, если не обнаружит там возможностей по разыменованию (совпадения по имени), обратиться уже к демону systemd-resolved с просьбой сделать это для себя любимой. Ранее в этой строке у вас скорее всего было упоминание слова "dns", заставляющее приложение самостоятельно обращаться к DNS серверам с целью резолвинга. Мы удалили эту возможность за более ненадобностью. К тому же этот способ значительно медленнее, чем обращение напрямую к локально установленному демону systemd-resolved, который, к слову, еще и поддерживает кэширование полученных записей. Конечно же, самое первое обращение всё равно будет сопровождаться запросом systemd-resolved к DNS серверам, но потом накопленный кэш существенно ускорит эти операции. Небольшое замечание: конечно же, приложение само не делает никаких обращений - оно просто не умеет. Всё это делается по средствам библиотечных вызовов. Именно поэтому мы доустанавливали библиотеки в начале статьи и именно поэтому использование systemd-resolved эффективнее, потому что библиотечные вызовы быстрее, чем обращения, производимые с использованием стека TCP/IP.
Открытым остался вопрос о том, как сообщить systemd-resolved IP-адреса DNS серверов, к которым следует обращаться для разыменования запросов приложений. Можно определить DNS сервера в файле /etc/systemd/resolved.conf, можно их определить в файлах ".network" демона systemd-networkd, а можно, пользуясь DHCP с привлечением того же systemd-networkd получать эти адреса автоматически от сервера DHCP. Но для этого у вас должен быть запущен и настроен systemd-networkd. Если его нет, или вы не хотите его использовать, то единственным вариантом остается /etc/systemd/resolved.conf.
Для целей совместимости с приложениями, которые по каким-либо причинам не используют библиотечные вызовы, а обращаются к DNS серверам напрямую, получая их IP-адреса из /etc/resolv.conf, следует создать символическую ссылку:
ln -svi /run/systemd/resolve/resolv.conf /etc/resolv.conf
ls -la /etc/resolv.conf
lrwxrwxrwx 1 root root 32 дек 13 09:11 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf
Нам остается только запустить сервис и наслаждаться резолвингом с помощью systemd-resolved:
systemdctl enable systemd-resolved
systemdctl start systemd-resolved
LLMNR в systemd-resolved
Отдельного упоминания заслуживает поддержка в systemd-resolved протокола LLMNR (Link-Local Multicast Name Resolution). Этот протокол позволяет узлам в одной сети (широковещательном домене) обращаться друг к другу по имени хоста, не прибегая к услугам DNS вообще. Работает это следующим образом: какая-нибудь программа пытается обратиться к хосту в своей сети по имени, используя, как мы уже упоминали, библиотечные вызовы; локальный DNS-резолвер, как например герой нашей статьи - systemd-resolved, сначала попытается найти запрашиваемый хост в своей сети, делая групповой запрос на адрес 224.0.0.252 для ipv4 и FF02::1:3 для ipv6; если в сети есть хосты с поддержкой LLMNR и среди них окажется тот, имя которого будет соответствовать запрашиваемому, systemd-resolved незамедлительно вернет запрашивающей программе IP-адрес интересующего ее хоста. Однако стоит заметить, что для работы этого протокола очень важно правильно конфигурировать hostname на каждом компьютере в сети. Вы должны использовать короткую нотацию - не FQDN. В linux имя хоста указывается в /etc/hostname. Вы также можете использоать команду 'hostnamectl set-hostname NAME' для горячего изменения hostname компьютера. Ну и конечно же, LLMNR должен быть включен в вашем systemd-resolved. Это можно проверить по выводу команды ss:
ss -ntpul | grep 5355
udp UNCONN 0 0 *:5355 *:* users:(("systemd-resolve",pid=15784,fd=12))
udp UNCONN 0 0 . 5355 . * users:(("systemd-resolve",pid=15784,fd=11))
tcp LISTEN 0 128 *:5355 *:* users:(("systemd-resolve",pid=15784,fd=14))
tcp LISTEN 0 128 . 5355 . * users:(("systemd-resolve",pid=15784,fd=15))
Читайте также: