Systemd resolved что это
Переходим на systemd-resolved
Установка и первичная настройка systemd-resolved
Для работы с systemd-resolved вам понадобится демон systemd-resolved. В Ubuntu он уже входит в пакет systemd (в 16.04 точно), а вот в Centos 7 его придется доустановить:
yum install systemd-resolved
В Centos эта библиотека входит в пакет systemd-resolved, а в ubuntu придется выполнить:
apt install libnss-resolve
Следующим шагом будет правка файла /etc/nsswitch.conf. Находим строчку, начинающуюся с «hosts:» и приводим к виду:
hosts: files resolve
Открытым остался вопрос о том, как сообщить 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, следует создать символическую ссылку:
Нам остается только запустить сервис и наслаждаться резолвингом с помощью systemd-resolved:
systemdctl enable systemd-resolved
systemdctl start systemd-resolved
LLMNR в systemd-resolved
В завершении статьи небольшое отступление, советы по использованию:
Пошаговые руководства, шпаргалки, полезные ссылки.
Инструменты пользователя
Инструменты сайта
Боковая панель
Настройка кеширующего DNS-клиента systemd-resolved в Debian GNU/Linux 9 (Stretch)
В конфигурации по умолчанию данная служба не запущена:
Установим модуль nss-resolve (библиотека libnss_resolve.so из пакета libnss-resolve) для механизма Name Service Switch (NSS), который будет вызывать службу systemd-resolved для разрешения имён:
В процессе установки в конфигурационном файле /etc/nsswitch.conf строка hosts: files dns будет автоматически заменена на следующий вид:
Теперь осталось только включить автозагрузку службы и запустить её:
Дополнительные источники информации:
Проверено на следующих конфигурациях:
Автор первичной редакции:
Алексей Максимов
Время публикации: 27.12.2017 11:29
Обсуждение
Речь идет о почтовом сервере. Через раз получаю ошибку «StatusDnsQueryFailed resolving domain»
От англ мануала по PowerMTA
«Эта ошибка указывает на то, что DNS-запрос для домена не может быть завершен. Это может быть вызвано несколькими причинами, а именно тайм-аутами, когда PowerMTA пытается установить соединение с вашим локальным DNS-сервером, но, скорее всего, тайм-аутами на самом локальном DNS-сервере при попытке установить соединение с другими DNS-серверами.»
Сейчас прописал явно в resolv.conf
option timeout:1
option rotate
domain c-premier.ru
nameserver 77.88.8.8
nameserver 8.8.8.8
nameserver 77.88.8.1
nameserver 8.8.4.4
search c-premier.ru
не было domain / search и еще были ipv6 адреса
вроде пока работает.. У меня такая ошибка (да и не только у меня) в этой программе на всех серверах.
Первый раз вооще сталкиваюсь с resolv..м
Настройка DNS на Ubuntu Server 18.04 LTS
При этом файл resolv.conf заменяется символической ссылкой на /run/resolvconf/resolv.conf и программы используют динамически сгенерированный файл. В системе без службы resolvconf.service файл resolv.conf поддерживается вручную или набором скриптов. И эти скрипты могут мешать друг другу при попытках одновременного доступа к файлу.
Всё это привело к тому, что теперь в одной системе порт 53 может слушать несколько разных резолверов, причём для избежания конфликтов NetworkManager и systemd-resolved используют вместо 127.0.0.1 другие ip-адреса в loopback-сети:
Настройка службы systemd-resolved
В Ubuntu Server эта служба уже установлена и запущена сразу после установки операционной системы. Но если это не так, установить ее несложно:
Следующим шагом будет правка файла /etc/nsswitch.conf — находим строку, которая начинается с hosts :
Осталось сообщить systemd-resolved ip-адреса DNS-серверов, к которым следует обращаться для резолвинга:
В файле /run/systemd/resolve/stub-resolv.conf указан один-единственный сервер 127.0.0.53 :
Как видите, у меня DNS-серверов получилось слишком много, так что последняя запись может быть проигнорирована. Все готово, остается только разрешить запуск службы при загрузке системы, если это еще не было сделано:
Настройка службы resolvconf.service
Служба предоставляет остальным программам централизованный интерфейс для добавления и удаления записей в /etc/resolv.conf при изменении сетевой конфигурации, запуске и остановке процессов и т.д.
Теперь добавим пару записей в файл tail (сервера OpenDNS):
Перезагрузим службу и посмотрим сформированный /run/resolvconf/resolv.conf :
Используем только resolv.conf
Для Ubuntu Desktop запретим вездесущему NetworkManager вмешиваться в процесс распознавания доменных имен:
Остановим службы resolvconf.service и systemd-resolved.service :
Проверим, как теперь работает распознавание доменных имен:
Чиним резолвинг адресов в VPN-локалке (openconnect) для docker и systemd-resolved
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 может указывать на несколько мест:
Саму ссылку /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. Это можно посмотреть командой:
Когда в 127.0.0.53 приходит запрос на разрешение имени, systemd-resolved смотрит search domain у каждого из коннектов (эти домены он при подключении от DHCP получил тоже). Домены можно посмотреть командой:
Далее имя хоста проверяется на частичное совпадение с теми доменами, которые прикреплены к коннектам и самое длинное совпадение и определяет какой конкретно 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 будет такое:
Если надо показать сервисы хост машины для доступа из контейнера, то просто запускаем сервисы слушать на docker0 IP и получаем доступ.
Не забываем открыть порты, например у меня 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 на хосте, который резолвит имена в локальной сети, работающий докер, который может резолвить эти адреса как родные.
Операционные системы Astra Linux
Оперативные обновления и методические указания
Операционные системы Astra Linux предназначены для применения в составе информационных (автоматизированных) систем в целях обработки и защиты 1) информации любой категории доступа 2) : общедоступной информации, а также информации, доступ к которой ограничен федеральными законами (информации ограниченного доступа).
1) от несанкционированного доступа;
2) в соответствии с Федеральным законом от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (статья 5, пункт 2).
Операционные системы Astra Linux Common Edition и Astra Linux Special Edition разработаны коллективом открытого акционерного общества «Научно-производственное объединение Русские базовые информационные технологии» и основаны на свободном программном обеспечении. С 17 декабря 2019 года правообладателем, разработчиком и производителем операционной системы специального назначения «Astra Linux Special Edition» является ООО «РусБИТех-Астра».
На web-сайтах https://astralinux.ru/ и https://wiki.astralinux.ru представлена подробная информация о разработанных операционных системах семейства Astra Linux, а также техническая документация для пользователей операционных систем и разработчиков программного обеспечения.
Мы будем признательны Вам за вопросы и предложения, которые позволят совершенствовать наши изделия в Ваших интересах и адаптировать их под решаемые Вами задачи!
Репозитория открытого доступа в сети Интернет для операционной системы Astra Linux Special Edition нет. Операционная система распространяется посредством DVD-дисков.
Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить в статье Подключение репозиториев с пакетами в ОС Astra Linux и установка пакетов.
В целях обеспечения соответствия сертифицированных операционных систем Astra Linux Special Edition требованиям, предъявляемым к безопасности информации, ООО «РусБИтех-Астра» осуществляет выпуск очередных и оперативных обновлений.
Очередные обновления (версии) предназначены для:
Оперативные обновления предназначены для оперативного устранения уязвимостей в экземплярах, находящихся в эксплуатации, и представляют собой бюллетень безопасности, который доступен в виде:
Ввиду совершенствования нормативно-правовых документов в области защиты информации и в целях обеспечения соответствия информационных актуальным требованиям безопасности информации, а также обеспечения их долговременной эксплуатации, в том числе работоспособности на современных средствах вычислительной техники, рекомендуется на регулярной основе планировать проведение мероприятий по применению очередных и оперативных обновлений операционной системы.