Mon serveur Centos 7 ne résout pas correctement les noms de domaine. D'après ce que je vois, dans les systèmes Linux modernes /etc/resolv.confest souvent généré avec dhclient, dnsmasqou Network Manager.

J'ai donc une question théorique générale sur la pile réseau dans les Linux modernes:

Qui est responsable de la lecture /etc/resolv.conf? Quels acteurs (services ou sous-systèmes du noyau) sont impliqués dans la résolution des noms de domaine?

RÉPONSE COURTE: Le manuel Arch linux indique que la configuration de haut niveau de la résolution des noms de domaine est effectuée dans /etc/nsswitch.conf et s'appuie sur l' glibcAPI Name Service Switch .

glibcutilise la nss-resolvefonction pour envoyer des requêtes DNS aux serveurs DNS.

Normalement, les systèmes CentOS modernes nss-resolve dépendent du systemd-resolved service. Si a /etc/resolv.confété généré par quelque chose comme dhclient-script, le systemd-resolvedlit et fonctionne dans un mode de compatibilité, émulant le comportement d'anciens systèmes comme BINDle client DNS.

Les bibliothèques client DNS le font.

Les bibliothèques C contiennent des clients DNS qui regroupent les recherches nom-à-adresse dans le protocole DNS et les remettent aux serveurs DNS proxy pour effectuer tout le travail de résolution des requêtes. Il y a beaucoup de ces clients DNS. Celui qui se trouve dans la bibliothèque d'exécution C principale de votre système d'exploitation sera très probablement celui de BIND d'ISC. Mais il y dnsen a beaucoup d'autres de la bibliothèque de Daniel J. Bernstein à travers c-ares à adns.

Bien que plusieurs d'entre eux contiennent leurs propres mécanismes de configuration natifs, ils ont généralement un mode de compatibilité de bibliothèque BIND où ils lisent resolv.conf, qui est le fichier de configuration de la bibliothèque client BIND C de l'ISC.

Le NSS est superposé en plus de cela et est configuré par nsswitch.conf. L'une des choses que les recherches NSS peuvent invoquer en interne est le client DNS, et nsswitch.confest lu par le code NSS dans la bibliothèque C pour déterminer si et où les recherches sont transmises au client DNS et comment gérer les différentes réponses.

(Il y a une légère complication à cette idée causée par le Name Services Cache Dæmon, nscd. Mais cela ajoute simplement un client de couche supérieure supplémentaire dans la bibliothèque C, parlant un protocole idiosyncrasique à un serveur local, qui à son tour agit comme un Un client DNS parlant le protocole DNS à un serveur DNS proxy systemd-resolvedajoute des complications similaires.)

systemd-resolved, NetworkManager, connman, dhcpcd, resolvconfEt d' autres ajuster le fichier de configuration du client DNS BIND aux clients DNS de passer à parler à différents serveurs DNS proxy à la volée. Cela est hors de portée pour cette réponse, d'autant plus qu'il existe de nombreuses réponses sur ce site WWW traitant déjà des détails byzantins qu'un tel mécanisme implique.

La manière la plus traditionnelle de faire les choses dans le monde Unix consiste à exécuter un serveur DNS proxy sur la machine elle-même ou sur un réseau local. D'où ce que dit le manuel de FreeBSD sur les systèmes normalement configurés, où l'action par défaut de la bibliothèque client DNS en l'absence de resolv.confcorrespond à ce que les administrateurs système Unix ont normalement, qui est un serveur DNS proxy écoutant sur 127.0.0.1. (Le manuel FreeBSD pour resolv.confest en fait un doco qui provient également de BIND d'ISC, et peut bien sûr aussi être trouvé là où la bibliothèque cliente DNS BIND a été incorporée dans d'autres endroits tels que la bibliothèque GNU C.)

Lectures complémentaires

• Daniel J. Bernstein. La dnsbibliothèque . cr.yp.to.
• Jonathan de Boyne Pollard (2017). Qu'est-ce que la qualification de nom DNS ? Réponses fréquemment données.
• Jonathan de Boyne Pollard (2004). Quelle est la résolution des requêtes DNS . Réponses fréquemment données.
• Jonathan de Boyne Pollard (2001). Vue d'ensemble de "djbdns" . Réponses fréquemment données.
• Jonathan de Boyne Pollard (2000). Serveurs DNS "contenu" et "proxy". Réponses fréquemment données.

Depuis la page de manuel de FreeBSD bien meilleure, 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.

Le fichier /etc/resolv.confest lu par des appels * libc qui effectuent la résolution du nom d'hôte. C'est principalement getaddrinfoet le déprécié gethostbyname.

Si ces fonctions reçoivent un nom DNS, elles effectuent ces opérations dans l'ordre suivant:

1. Essayez de résoudre le nom d'hôte localement, c'est-à-dire en lisant /etc/hosts.
2. Si cela échoue, interrogez les serveurs DNS répertoriés dans /etc/resolv.conf.
3. Si cela échoue également, le nom d'hôte ne peut pas être résolu.

Puisque vous mentionnez dnsmasq : il s'agit d'un serveur DNS qui s'exécute localement. Donc, sur de nombreuses distributions Linux modernes, le /etc/resolv.confseul point vers 127.0.0.1(c'est là que le dnsmasq local écoute). dnsmasq est ensuite configuré pour transférer les requêtes des serveurs DNS Internet; dnsmasq est configuré par Network Manager lors de la connexion à Internet.