Мой сервер Centos 7 не разрешает доменные имена должным образом. Из того, что я вижу, в современных системах Linux /etc/resolv.confчасто генерируются dhclient, dnsmasqили Network Manager.

Таким образом, у меня есть общий теоретический вопрос о сетевом стеке в современных Linux:

Кто отвечает за чтение /etc/resolv.conf? Какие игроки (сервисы или подсистемы ядра) участвуют в разрешении доменных имен?

КРАТКИЙ ОТВЕТ: Руководство Arch linux говорит, что высокоуровневая настройка разрешения доменного имени выполнена /etc/nsswitch.conf и использует glibcAPI переключения службы имен .

glibcиспользует nss-resolveфункцию для отправки DNS-запросов на DNS-серверы.

Обычно на современных системах CentOS nss-resolve полагается на systemd-resolved сервис. Если /etc/resolv.confгенерируется что-то вроде dhclient-script, systemd-resolvedчитает и работает в режиме совместимости, эмулируя поведение старых систем, таких как BINDDNS-клиент.

Клиентские библиотеки DNS делают.

Библиотеки C содержат клиентов DNS, которые оборачивают поиск по имени в протоколе DNS и передают их на прокси-серверы DNS, чтобы выполнить всю основную работу по разрешению запросов. Есть много таких DNS-клиентов. Вероятно, тот, что находится в основной библиотеке времени выполнения C вашей операционной системы, будет из библиотеки BIND ISC. Но есть целая масса других из dnsбиблиотеки Дэниела Дж. Бернштейна через c-ares to adns.

Хотя некоторые из них содержат собственные механизмы конфигурации, они обычно имеют режим совместимости библиотеки BIND, в котором они читают resolv.conf, - это файл конфигурации клиентской библиотеки BIND C ISC.

NSS имеет многоуровневую структуру и настраивается с помощью nsswitch.conf. Одна из вещей, которую NSS-запросы могут вызывать изнутри, - это DNS-клиент, nsswitch.confкоторый читается кодом NSS в библиотеке C, чтобы определить, передаются ли и где запросы на DNS-клиент, и как обрабатывать различные ответы.

(Существует небольшая сложность этой идеи, вызванная Dmon-ом кэша служб имен, nscd. Но это просто добавляет дополнительного клиента верхнего уровня в библиотеку C, говорящего на локальном сервере с уникальным протоколом, который, в свою очередь, действует как DNS-клиент, говорящий по протоколу DNS с прокси-сервером DNS, systemd-resolvedдобавляет аналогичные сложности.)

systemd-resolved, NetworkManager, connman, dhcpcd, resolvconf, И другие регулировки конфигурации клиента файл BIND DNS для переключения DNS клиентов , чтобы поговорить с различными прокси - серверами DNS на лету. Это выходит за рамки этого ответа, тем более что на этом WWW-сайте есть множество ответов, уже посвященных византийским деталям, которые включает в себя такой механизм.

Более традиционный способ работы в мире Unix - запуск прокси-DNS-сервера либо на самой машине, либо в локальной сети. Отсюда то, что в руководстве FreeBSD говорится о нормально сконфигурированных системах, где действие по умолчанию клиентской библиотеки DNS при отсутствии resolv.confсовпадает с тем, что обычно имеют системные администраторы Unix, то есть прокси-сервер DNS, прослушивающий 127.0.0.1. (Руководство FreeBSD для resolv.confфактически DOCO что также происходит от BIND ISC, и , конечно , могут также быть найдены где клиентская библиотека BIND DNS была включена в другие места , такие как библиотеки GNU C) .

дальнейшее чтение

• Даниэль Дж. Бернштейн. Библиотека . cr.yp.to.dns
• Джонатан де Бойн Поллард (2017). Что DNS имя квалификации . Часто задаваемые ответы.
• Джонатан де Бойн Поллард (2004). Что такое разрешение DNS-запросов . Часто задаваемые ответы.
• Джонатан де Бойн Поллард (2001). Большая картина для "djbdns" . Часто задаваемые ответы.
• Джонатан де Бойн Поллард (2000). DNS-серверы «контент» и «прокси». Часто задаваемые ответы.

Из гораздо лучшей справочной страницы FreeBSD, resolv.conf :

 The resolver configuration file contains information that is read by the
 resolver routines the first time they are invoked by a process.

 On a normally configured system this file should not be necessary.  The
 only name server to be queried will be on the local machine, the domain
 name is determined from the host name, and the domain search path is
 constructed from the domain name.

Файл /etc/resolv.confчитается с помощью вызовов * libc, которые выполняют разрешение имени хоста. Это в первую очередь getaddrinfoи не рекомендуется gethostbyname.

Если этим функциям передается DNS-имя, они делают это в следующем порядке:

1. Попробуйте разрешить имя хоста локально, то есть путем чтения /etc/hosts.
2. Если это не удается, тогда запросите DNS-серверы, перечисленные в /etc/resolv.conf.
3. Если это также не удается, то имя хоста не может быть разрешено.

Поскольку вы упоминаете dnsmasq : это DNS-сервер, который работает локально. Таким образом, во многих современных дистрибутивах Linux /etc/resolv.confединственное, на что указывает 127.0.0.1(это то, что слушает локальный dnsmasq). Затем dnsmasq настроен на пересылку запросов интернет-DNS-серверам; dnsmasq настраивается Network Manager при подключении к Интернету.