Ресолвер: различия между версиями
(created) |
Pauli (обсуждение | вклад) м (→Введение) |
||
| (не показано 11 промежуточных версий 6 участников) | |||
| Строка 1: | Строка 1: | ||
'''Ресолвер''' — механизм преобразования имен хостов в адреса IP. | '''Ресолвер''' — механизм преобразования имен хостов в адреса IP. | ||
Включает в себя '''glibc''', '''libresolv''', использует '''/etc/resolv.conf''', '''/etc/hosts''', '''/etc/nsswitch.conf''' | Включает в себя '''glibc''', '''libresolv''', использует '''/etc/resolv.conf''', '''/etc/hosts''', '''/etc/nsswitch.conf''' | ||
В | В ALT дополнительно используются '''/etc/net/ifaces/*/resolv.conf''', '''systemd-resolved''', '''openresolv''' | ||
== Введение == | == Введение == | ||
Лучшее понимание механизмов преобразования имен хостов в адреса IP позволит быстрее диагностировать ошибки. | Лучшее понимание механизмов преобразования имен хостов в адреса IP позволит быстрее диагностировать ошибки. | ||
Преобразованием имен хостов в адреса занимается glibc на основе | |||
различных источников данных (/etc/hosts, mDNS, winbind, dns, ldap и | различных источников данных (<tt>/etc/hosts</tt>, mDNS, winbind, dns, ldap и | ||
т.п.). Это модульная система | т. п.). Это модульная система, можно добавить много различных модулей. | ||
Источники для преобразования имён в адреса указаны в {{cmd|grep hosts /etc/nsswitch.conf}}: | |||
hosts: files dns myhostname | hosts: files dns myhostname | ||
Например, добавив в | Например, добавив в строку <tt>hosts:</tt> параметр <tt>mymachines</tt> (пакет libnss-mymachines), | ||
сможем обращаться к нашим контейнерам systemd-nspawn по именам. | мы сможем обращаться к нашим контейнерам <tt>systemd-nspawn</tt> по именам. | ||
Мы сейчас говорим о модуле dns (/lib{,64}/libnss_dns.so) который | Мы сейчас говорим о модуле dns (<tt>/lib{,64}/libnss_dns.so</tt>), который слинкован с libresolv. | ||
слинкован с libresolv. Именно в libresolv определено использование | Именно в libresolv определено использование <tt>/etc/resolv.conf</tt>. | ||
/etc/resolv.conf. | |||
С вводной частью закончили, давайте перейдём к практике и рассмотрим | С вводной частью закончили, давайте перейдём к практике и рассмотрим, кто и как наполняет этот <tt>/etc/resolv.conf</tt>. | ||
кто и как наполняет этот /etc/resolv.conf | |||
== etcnet == | == etcnet == | ||
В etcnet 2 варианта, для статической настройки | В [[etcnet]] есть 2 варианта создания <tt>/etc/resolv.conf</tt>, один для статической настройки, другой для DHCP. | ||
* для статики все просто, файл копируется из /etc/net/ifaces/foo/resolv.conf в /etc/resolv.conf | * для статики все просто, файл копируется из <tt>/etc/net/ifaces/foo/resolv.conf</tt> в <tt>/etc/resolv.conf</tt> | ||
* для DHCP посложнее. dhcpcd получает данные от | * для DHCP посложнее. {{cmd|dhcpcd}} получает данные от сервера DHCP, а дальше с помощью хуков (<tt>/lib/dhcpcd/dhcpcd-hooks/20-resolv.conf</tt>) обновляет <tt>/etc/resolv.conf</tt> | ||
== openresolv == | == openresolv == | ||
openresolv был придуман для того, что бы во время работы при смене DNS удобно управлять <tt>/etc/resolv.conf</tt>. | |||
Оправдан, кода вы одни | Оправдан, кода вы одни серверы DNS получили от сервера DHCP, а другие — от соединения VPN. | ||
Когда у нас происходит настройка на | Когда у нас происходит настройка на серверы DNS только один раз при загрузке, то использовать openresolv нет необходимости. Возможно даже вредно, т. к. это вносит еще один элемент (прокладку) во всю эту хрупкую конструкцию. | ||
При наличии openresolv в системе, etcnet начинает автоматически использовать её, поэтому копирование /etc/net/ifaces/foo/resolv.conf в /etc/resolv.conf или наполнение /etc/resolv.conf данными от DHCP | При наличии openresolv в системе, etcnet начинает автоматически использовать её, поэтому копирование <tt>/etc/net/ifaces/foo/resolv.conf</tt> в <tt>/etc/resolv.conf</tt> или наполнение <tt>/etc/resolv.conf</tt> данными от сервера DHCP происходит не напрямую, а через вызов {{cmd|/sbin/resolvconf}}. | ||
Надо еще упомянуть, что openresolv умеет готовить конфиги для dnsmasq, | Надо еще упомянуть, что openresolv умеет готовить конфиги для dnsmasq, unbound, pdns, bind, если они используются как локальные серверы DNS. | ||
unbound, pdns, bind, если они используются как локальные | |||
== systemd-resolved == | == systemd-resolved == | ||
systemd-resolved — это по сути маленький локальный кэширующий dns-сервер, принимающий запросы на 127.0.0.53:53. Его можно с натяжкой сравнить с dnsmasq, unbound, knot- | systemd-resolved — это по сути маленький локальный кэширующий dns-сервер, принимающий запросы на 127.0.0.53:53. Его можно с натяжкой сравнить с dnsmasq, unbound, knot-resolver (конечно, они гораздо мощнее и гибче), но он умеет, например, DNSSEC и DNS-Over-TLS. | ||
Кроме этого он предоставляет API для взаимодействия напрямую через вызовы библиотеки, а не через | Кроме этого, он предоставляет API для взаимодействия напрямую через вызовы библиотеки, а не через запросы по UDP. | ||
Добавив в nsswitch.conf | Добавив в <tt>nsswitch.conf</tt> | ||
hosts: resolve | hosts: resolve | ||
(пакет libnss-resolve) | (пакет libnss-resolve), | ||
мы сможем резолвить имена без (/lib{,64}/libnss_dns.so) и без обращения к /etc/resolv.conf. /etc/resolv.conf он тоже умеет читать, но никак его не модифицирует. | мы сможем резолвить имена без (<tt>/lib{,64}/libnss_dns.so</tt>) и без обращения к <tt>/etc/resolv.conf</tt>. <tt>/etc/resolv.conf</tt> он тоже умеет читать, но никак его не модифицирует. | ||
Скажем так, у systemd-resolved свой resolv.conf, который находится в /run/systemd/resolve. И не один. | Скажем так, у systemd-resolved свой resolv.conf, который находится в <tt>/run/systemd/resolve</tt>. И не один. | ||
Чтобы glibc продолжал работать с nss-модулем dns, systemd-resolved может предоставить для него resolv.conf | Чтобы glibc продолжал работать с nss-модулем dns, systemd-resolved может предоставить для него resolv.conf | ||
; а) статический /lib/systemd/resolv.conf в котором указан nameserver 127.0.0.53. | ; а) статический /lib/systemd/resolv.conf в котором указан nameserver 127.0.0.53. | ||
сделав симлинк /etc/resolv.conf → /lib/systemd/resolv.conf, мы укажем нашей системе использовать systemd-resloved как локальный | сделав симлинк <tt>/etc/resolv.conf → /lib/systemd/resolv.conf</tt>, мы укажем нашей системе использовать systemd-resloved как локальный сервер DNS. | ||
; б) сгенерированный /run/systemd/resolve/stub-resolv.conf | ; б) сгенерированный /run/systemd/resolve/stub-resolv.conf | ||
Вот на него более правильно делать симлинк /etc/resolv.conf. В нём также указан nameserver 127.0.0.53, но еще могут быть указаны домены поиска | Вот на него более правильно делать симлинк <tt>/etc/resolv.conf</tt>. В нём также указан nameserver 127.0.0.53, но еще могут быть указаны домены поиска: | ||
search example.com | |||
; в) сгенерированный /run/systemd/resolve/resolv.conf | ; в) сгенерированный /run/systemd/resolve/resolv.conf | ||
В нём указаны реальные DNS | В нём указаны реальные серверы DNS. Т. е., скопировав в /etc/resolv.conf (или симлинк), приложения (glibc nss-dns) перестанут использовать локальный кэширующий dns-сервер systemd-resolved и начнут напрямую использовать указанные серверы. | ||
Информация в этот сгенерированный файл попадает из файлов /etc/systemd/network/*.network и /etc/systemd/resolved.conf (DNS=…, Domains=…) | Информация в этот сгенерированный файл попадает из файлов <tt>/etc/systemd/network/*.network</tt> и <tt>/etc/systemd/resolved.conf</tt> (DNS=…, Domains=…) | ||
Эти же данные используются и для работы самого systemd-resolved. | Эти же данные используются и для работы самого systemd-resolved. | ||
== NetworkManager == | == NetworkManager == | ||
[[NetworkManager]] по | [[NetworkManager]] по умолчанию использует встроенный клиент DHCP, но может и внешний. | ||
Можно определить в /etc/NetworkManager/conf.d/dhcp-client.conf: | Можно определить в <tt>/etc/NetworkManager/conf.d/dhcp-client.conf</tt>: | ||
[main] | [main] | ||
dhcp=dhcpcd или dhclient (по умолчанию internal) | dhcp=dhcpcd или dhclient (по умолчанию internal) | ||
Так же он может использовать dnsmasq, unbound или systemd-resolved в качестве локального | Так же он может использовать dnsmasq, unbound или systemd-resolved в качестве локального сервера DNS (dns=dnsmasq). | ||
При этом не надо отдельно стартовать dnsmasq или unbound, он их сам запустит и настроит (подсунет конфиг). | При этом не надо отдельно стартовать dnsmasq или unbound, он их сам запустит и настроит (подсунет конфиг). | ||
Если /etc/resolv.conf является симлинком на один из systemd-resolved конфигов, NM это понимает и использует systemd-resolved | Если <tt>/etc/resolv.conf</tt> является симлинком на один из systemd-resolved конфигов, NM это понимает и использует systemd-resolved | ||
(не трогает /etc/resolv.conf). | (не трогает <tt>/etc/resolv.conf</tt>). | ||
А вот если | А вот если <tt>/etc/resolv.conf</tt> не симлинк, а файл, то NM начинает его изменять (указывает nameserver для статического или DHCP адреса), используя openresolv (собран с параметром <tt>--with-config-dns-rc-manager-default=resolvconf</tt>). | ||
По аналогии с systemd-resolved NM генерирует resolv.conf в /run/NetworkManager/resolv.conf и /run/NetworkManager/no-stub-resolv.conf | По аналогии с systemd-resolved NM генерирует resolv.conf в <tt>/run/NetworkManager/resolv.conf</tt> и <tt>/run/NetworkManager/no-stub-resolv.conf</tt> | ||
== update_chrooted == | == [[Features/ChrootedServices|update_chrooted]] == | ||
: Наши замечательные ALT особенности | : Наши замечательные ALT особенности | ||
Множество сервисов и отдельных программ(например ping) запускаются в chroot. | Множество сервисов и отдельных программ(например ping) запускаются в chroot. | ||
В этот chroot должны быть скопированы и библиотеки, и настройки для этих библиотек, в частности resolv.conf. | В этот chroot должны быть скопированы и библиотеки, и настройки для этих библиотек, в частности resolv.conf. | ||
Т. е. ping не использует /etc/resolv.conf, а использует /var/resolv/etc/resolv.conf. | Т. е. ping не использует <tt>/etc/resolv.conf</tt>, а использует <tt>/var/resolv/etc/resolv.conf</tt>. | ||
Нам очень важно держать в chroot'ах resolv.conf синхронным c основной системой. | Нам очень важно держать в chroot'ах resolv.conf синхронным c основной системой. | ||
<br> | <br> | ||
Вроде все утилиты, обновляющие /etc/resolv.conf обучены вызывать update_chrooted. | Вроде все утилиты, обновляющие <tt>/etc/resolv.conf</tt>, обучены вызывать {{cmd|update_chrooted conf}}. | ||
=== Первая глобальная проблема === | === Первая глобальная проблема === | ||
update_chroot не | {{cmd|update_chroot}} не предполагал симлинка <tt>/etc/resolv.conf</tt> до версии chrooted-0.3.11-alt1: <s>{{altbug|33591}}</s> | ||
<br> | <br> | ||
Проблема возникала в системах с systemd, на текущий момент нужная версия chrooted присутствует в ветках, начиная с p8. | |||
=== Вторая проблема === | === Вторая проблема === | ||
Как изменение resolv.conf обрабатывать в systemd. | Как изменение resolv.conf обрабатывать в {{cmd|systemd}}. | ||
<br> | <br> | ||
Если используются etcnet или NetworkManager то они за собой дёргают update_chrooted. | Если используются etcnet или NetworkManager то они за собой дёргают {{cmd|update_chrooted}}. | ||
А вот systemd-networkd и systemd-resolved не имеют возможности запустить какой либо хук. | А вот {{cmd|systemd-networkd}} и {{cmd|systemd-resolved}} не имеют возможности запустить какой либо хук. | ||
== Дополнительные сервисы в systemd == | == Дополнительные сервисы в systemd == | ||
(Для решения второй проблемы с update_chrooted) systemd умеет отслеживать изменение файлов и запускать по событию сервис. | (Для решения второй проблемы с {{cmd|update_chrooted}}) {{cmd|systemd}} умеет отслеживать изменение файлов и запускать по событию сервис. | ||
Были написаны сервисы altlinux-libresolv.path (отслеживает изменения) и altlinux-libresolv.service (запускает /etc/chroot.d/resolv.conf). | Были написаны сервисы {{cmd|altlinux-libresolv.path}} (отслеживает изменения) и {{cmd|altlinux-libresolv.service}} (запускает <tt>/etc/chroot.d/resolv.conf</tt>). | ||
Для обновления /etc/resolv.conf без использования openresolv были написаны сервисы altlinux-simpleresolv.path и altlinux-simpleresolv.service | Для обновления <tt>/etc/resolv.conf</tt> без использования {{cmd|openresolv}} были написаны сервисы {{cmd|altlinux-simpleresolv.path}} и {{cmd|altlinux-simpleresolv.service}} | ||
Для обновления /etc/resolv.conf с ипользование openresolv были написаны сервисы altlinux-openresolv.path и altlinux-openresolv.service | Для обновления <tt>/etc/resolv.conf</tt> с ипользование openresolv были написаны сервисы {{cmd|altlinux-openresolv.path}} и {{cmd|altlinux-openresolv.service}} | ||
== dnsmasq == | |||
Если используется dnsmasq, то он сам перезаписывает /etc/resolv.conf в соответствии со своей конфигурацией. | |||
== Подведение итогов и рекомендации == | == Подведение итогов и рекомендации == | ||
* systemd-resolved работает в связке с systemd-networkd. Можно конечно и без, но это создание дополнительных трудностей. Проще рекомендовать использовать systemd-resolved только с systemd-networkd. | * {{cmd|systemd-resolved}} работает в связке с {{cmd|systemd-networkd}}. Можно конечно и без, но это создание дополнительных трудностей. Проще рекомендовать использовать {{cmd|systemd-resolved}} только с {{cmd|systemd-networkd}}. | ||
* При использовании etcnet не пытайтесь использовать systemd-resolved. Можно конечно, но это создание дополнительных | * При использовании [[etcnet]] не пытайтесь использовать {{cmd|systemd-resolved}}. Можно конечно, но это создание дополнительных трудностей. Просто удалите пакет {{pkg|systemd-networkd}}. | ||
трудностей. Просто удалите пакет systemd-networkd. | |||
* NetworkManager вроде должен уметь работать в любых условиях с кем угодно. | * NetworkManager вроде должен уметь работать в любых условиях с кем угодно. | ||
== Примечания == | == Примечания == | ||
Источник — письмо <nowiki>Alexey Shabalin <a.shabalin@gmail.com></nowiki> в [http://lists.altlinux.org/pipermail/sisyphus sisyphus] (31 марта 2020 г.) «Приключения resolv.conf в ALT» | Источник — [http://lists.altlinux.org/pipermail/sisyphus/2020-March/368517.html письмо] <nowiki>Alexey Shabalin <a.shabalin@gmail.com></nowiki> в [http://lists.altlinux.org/pipermail/sisyphus sisyphus] (31 марта 2020 г.) «Приключения resolv.conf в ALT» | ||
== См. также == | == См. также == | ||
Текущая версия от 10:45, 22 мая 2024
Ресолвер — механизм преобразования имен хостов в адреса IP.
Включает в себя glibc, libresolv, использует /etc/resolv.conf, /etc/hosts, /etc/nsswitch.conf
В ALT дополнительно используются /etc/net/ifaces/*/resolv.conf, systemd-resolved, openresolv
Введение
Лучшее понимание механизмов преобразования имен хостов в адреса IP позволит быстрее диагностировать ошибки.
Преобразованием имен хостов в адреса занимается glibc на основе различных источников данных (/etc/hosts, mDNS, winbind, dns, ldap и т. п.). Это модульная система, можно добавить много различных модулей.
Источники для преобразования имён в адреса указаны в grep hosts /etc/nsswitch.conf:
hosts: files dns myhostname
Например, добавив в строку hosts: параметр mymachines (пакет libnss-mymachines), мы сможем обращаться к нашим контейнерам systemd-nspawn по именам.
Мы сейчас говорим о модуле dns (/lib{,64}/libnss_dns.so), который слинкован с libresolv. Именно в libresolv определено использование /etc/resolv.conf.
С вводной частью закончили, давайте перейдём к практике и рассмотрим, кто и как наполняет этот /etc/resolv.conf.
etcnet
В etcnet есть 2 варианта создания /etc/resolv.conf, один для статической настройки, другой для DHCP.
- для статики все просто, файл копируется из /etc/net/ifaces/foo/resolv.conf в /etc/resolv.conf
- для DHCP посложнее. dhcpcd получает данные от сервера DHCP, а дальше с помощью хуков (/lib/dhcpcd/dhcpcd-hooks/20-resolv.conf) обновляет /etc/resolv.conf
openresolv
openresolv был придуман для того, что бы во время работы при смене DNS удобно управлять /etc/resolv.conf. Оправдан, кода вы одни серверы DNS получили от сервера DHCP, а другие — от соединения VPN.
Когда у нас происходит настройка на серверы DNS только один раз при загрузке, то использовать openresolv нет необходимости. Возможно даже вредно, т. к. это вносит еще один элемент (прокладку) во всю эту хрупкую конструкцию.
При наличии openresolv в системе, etcnet начинает автоматически использовать её, поэтому копирование /etc/net/ifaces/foo/resolv.conf в /etc/resolv.conf или наполнение /etc/resolv.conf данными от сервера DHCP происходит не напрямую, а через вызов /sbin/resolvconf.
Надо еще упомянуть, что openresolv умеет готовить конфиги для dnsmasq, unbound, pdns, bind, если они используются как локальные серверы DNS.
systemd-resolved
systemd-resolved — это по сути маленький локальный кэширующий dns-сервер, принимающий запросы на 127.0.0.53:53. Его можно с натяжкой сравнить с dnsmasq, unbound, knot-resolver (конечно, они гораздо мощнее и гибче), но он умеет, например, DNSSEC и DNS-Over-TLS.
Кроме этого, он предоставляет API для взаимодействия напрямую через вызовы библиотеки, а не через запросы по UDP.
Добавив в nsswitch.conf
hosts: resolve
(пакет libnss-resolve), мы сможем резолвить имена без (/lib{,64}/libnss_dns.so) и без обращения к /etc/resolv.conf. /etc/resolv.conf он тоже умеет читать, но никак его не модифицирует.
Скажем так, у systemd-resolved свой resolv.conf, который находится в /run/systemd/resolve. И не один.
Чтобы glibc продолжал работать с nss-модулем dns, systemd-resolved может предоставить для него resolv.conf
- а) статический /lib/systemd/resolv.conf в котором указан nameserver 127.0.0.53.
сделав симлинк /etc/resolv.conf → /lib/systemd/resolv.conf, мы укажем нашей системе использовать systemd-resloved как локальный сервер DNS.
- б) сгенерированный /run/systemd/resolve/stub-resolv.conf
Вот на него более правильно делать симлинк /etc/resolv.conf. В нём также указан nameserver 127.0.0.53, но еще могут быть указаны домены поиска:
search example.com
- в) сгенерированный /run/systemd/resolve/resolv.conf
В нём указаны реальные серверы DNS. Т. е., скопировав в /etc/resolv.conf (или симлинк), приложения (glibc nss-dns) перестанут использовать локальный кэширующий dns-сервер systemd-resolved и начнут напрямую использовать указанные серверы.
Информация в этот сгенерированный файл попадает из файлов /etc/systemd/network/*.network и /etc/systemd/resolved.conf (DNS=…, Domains=…)
Эти же данные используются и для работы самого systemd-resolved.
NetworkManager
NetworkManager по умолчанию использует встроенный клиент DHCP, но может и внешний.
Можно определить в /etc/NetworkManager/conf.d/dhcp-client.conf:
[main] dhcp=dhcpcd или dhclient (по умолчанию internal)
Так же он может использовать dnsmasq, unbound или systemd-resolved в качестве локального сервера DNS (dns=dnsmasq). При этом не надо отдельно стартовать dnsmasq или unbound, он их сам запустит и настроит (подсунет конфиг).
Если /etc/resolv.conf является симлинком на один из systemd-resolved конфигов, NM это понимает и использует systemd-resolved (не трогает /etc/resolv.conf).
А вот если /etc/resolv.conf не симлинк, а файл, то NM начинает его изменять (указывает nameserver для статического или DHCP адреса), используя openresolv (собран с параметром --with-config-dns-rc-manager-default=resolvconf).
По аналогии с systemd-resolved NM генерирует resolv.conf в /run/NetworkManager/resolv.conf и /run/NetworkManager/no-stub-resolv.conf
update_chrooted
- Наши замечательные ALT особенности
Множество сервисов и отдельных программ(например ping) запускаются в chroot. В этот chroot должны быть скопированы и библиотеки, и настройки для этих библиотек, в частности resolv.conf. Т. е. ping не использует /etc/resolv.conf, а использует /var/resolv/etc/resolv.conf.
Нам очень важно держать в chroot'ах resolv.conf синхронным c основной системой.
Вроде все утилиты, обновляющие /etc/resolv.conf, обучены вызывать update_chrooted conf.
Первая глобальная проблема
update_chroot не предполагал симлинка /etc/resolv.conf до версии chrooted-0.3.11-alt1: altbug #33591
Проблема возникала в системах с systemd, на текущий момент нужная версия chrooted присутствует в ветках, начиная с p8.
Вторая проблема
Как изменение resolv.conf обрабатывать в systemd.
Если используются etcnet или NetworkManager то они за собой дёргают update_chrooted.
А вот systemd-networkd и systemd-resolved не имеют возможности запустить какой либо хук.
Дополнительные сервисы в systemd
(Для решения второй проблемы с update_chrooted) systemd умеет отслеживать изменение файлов и запускать по событию сервис. Были написаны сервисы altlinux-libresolv.path (отслеживает изменения) и altlinux-libresolv.service (запускает /etc/chroot.d/resolv.conf).
Для обновления /etc/resolv.conf без использования openresolv были написаны сервисы altlinux-simpleresolv.path и altlinux-simpleresolv.service
Для обновления /etc/resolv.conf с ипользование openresolv были написаны сервисы altlinux-openresolv.path и altlinux-openresolv.service
dnsmasq
Если используется dnsmasq, то он сам перезаписывает /etc/resolv.conf в соответствии со своей конфигурацией.
Подведение итогов и рекомендации
- systemd-resolved работает в связке с systemd-networkd. Можно конечно и без, но это создание дополнительных трудностей. Проще рекомендовать использовать systemd-resolved только с systemd-networkd.
- При использовании etcnet не пытайтесь использовать systemd-resolved. Можно конечно, но это создание дополнительных трудностей. Просто удалите пакет systemd-networkd.
- NetworkManager вроде должен уметь работать в любых условиях с кем угодно.
Примечания
Источник — письмо Alexey Shabalin <a.shabalin@gmail.com> в sisyphus (31 марта 2020 г.) «Приключения resolv.conf в ALT»