Кто читает /etc/resolv.conf?

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

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

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

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

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

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

Клиентские библиотеки 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-клиенту и как обрабатывать различные ответы.

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

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

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

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

  • Даниэль Дж. Бернштейн. Библиотека dns . cr.yp.to.
  • Джонатан де Бойн Поллард (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 при подключении к Интернету.