Il mio server Centos 7 non risolve correttamente i nomi di dominio. Da quello che vedo, nei moderni sistemi Linux /etc/resolv.confviene spesso generato con dhclient, dnsmasqo Network Manager.

Quindi ho una domanda teorica generale sullo stack di rete nei moderni Linux:

Chi è responsabile della lettura /etc/resolv.conf? Quali giocatori (servizi o sottosistemi kernel) sono coinvolti nella risoluzione dei nomi di dominio?

RISPOSTA BREVE: il manuale di Arch Linux dice che la configurazione di alto livello della risoluzione dei nomi di dominio è fatta /etc/nsswitch.conf e si basa sull'API Switch del nome del servizio glibc.

glibcutilizza la nss-resolvefunzione per inviare richieste DNS ai server DNS.

Normalmente sui moderni sistemi CentOS si nss-resolve affida al systemd-resolved servizio. Se è /etc/resolv.confstato generato da qualcosa di simile dhclient-script, lo systemd-resolvedlegge e funziona in una modalità di compatibilità, emulando il comportamento di sistemi più vecchi come BINDclient DNS.

Le librerie client DNS lo fanno.

Le librerie C contengono client DNS che racchiudono le ricerche da nome a indirizzo nel protocollo DNS e le consegnano ai server DNS proxy per svolgere tutto il duro lavoro di risoluzione delle query. Esistono molti di questi client DNS. Quello che si trova nella libreria di runtime C principale del tuo sistema operativo sarà molto probabilmente quello del BIND di ISC. Ma ce ne sono molti altri dalla dnsbiblioteca di Daniel J. Bernstein attraverso c-ares ad adns.

Sebbene molti di essi contengano i propri meccanismi di configurazione nativi, generalmente hanno una modalità di compatibilità della libreria BIND in cui leggono resolv.conf, che è il file di configurazione per la libreria client BIND C dell'ISC.

L'NSS è sovrapposto a questo, ed è configurato da nsswitch.conf. Una delle cose che le ricerche NSS possono invocare internamente è il client DNS e nsswitch.confviene letto dal codice NSS nella libreria C per determinare se e dove le ricerche vengono inviate al client DNS e come gestire le varie risposte.

(C'è una leggera complicazione a questa idea causata da Name Services Cache Dæmon, nscd. Ma questo aggiunge semplicemente un client di livello superiore extra nella libreria C, parlando di un protocollo idiosincratico a un server locale, che a sua volta funge da Client DNS che parla il protocollo DNS a un server DNS proxy. systemd-resolvedAggiunge complicazioni simili.)

systemd-resolved, NetworkManager, connman, dhcpcd, resolvconf, E altri regolare il file di configurazione del client BIND DNS per i client DNS interruttore di parlare con diversi server DNS del proxy al volo. Ciò non rientra nel campo di applicazione di questa risposta, soprattutto perché su questo sito WWW ci sono già molte risposte che trattano già dei dettagli bizantini che tale meccanismo comporta.

Il modo più tradizionale di fare le cose nel mondo Unix è di eseguire un server DNS proxy sulla macchina stessa o su una LAN. Da qui ciò che dice il manuale di FreeBSD sui sistemi normalmente configurati, in cui l'azione predefinita della libreria client DNS in assenza di resolv.confcorrispondenze è quella che normalmente hanno gli amministratori di sistema Unix, che è un server DNS proxy in ascolto su 127.0.0.1. (Il manuale di FreeBSD per resolv.confè in realtà un documento che proviene anche dal BIND di ISC, e ovviamente può anche essere trovato dove la libreria client DNS di BIND è stata incorporata in altri luoghi come la libreria GNU C.)

Ulteriori letture

• Daniel J. Bernstein. La dnsbiblioteca . cr.yp.to.
• Jonathan de Boyne Pollard (2017). Qual è la qualifica di nome DNS . Risposte frequentemente fornite.
• Jonathan de Boyne Pollard (2004). Qual è la risoluzione della query DNS . Risposte frequentemente fornite.
• Jonathan de Boyne Pollard (2001). Il quadro generale per "djbdns" . Risposte frequentemente fornite.
• Jonathan de Boyne Pollard (2000). server DNS "contenuto" e "proxy". Risposte frequentemente fornite.

Dalla pagina man di FreeBSD decisamente migliore, 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.

Il file /etc/resolv.confviene letto da * libc chiamate che eseguono la risoluzione del nome host. Questo è principalmente getaddrinfoe deprecato gethostbyname.

Se a queste funzioni viene passato un nome DNS, eseguono queste operazioni nel seguente ordine:

1. Prova a risolvere il nome host localmente, ovvero leggendo /etc/hosts.
2. In caso contrario, eseguire una query sui server DNS elencati in /etc/resolv.conf.
3. Se anche questo non riesce, il nome host non può essere risolto.

Da quando hai citato dnsmasq : questo è un server DNS che funziona localmente. Quindi, su molte distro Linux moderne, l' /etc/resolv.confunico punto 127.0.0.1(qui è dove il dnsmasq locale ascolta). dnsmasq è quindi configurato per inoltrare le query ai server DNS Internet; dnsmasq è configurato da Network Manager al momento della connessione a Internet.