Mój serwer Centos 7 nie rozpoznaje poprawnie nazw domen. Z tego co widzę, w nowoczesnych systemach Linux /etc/resolv.confjest często generowany dhclient, dnsmasqalbo Network Manager.

Tak więc mam ogólne teoretyczne pytanie dotyczące stosu sieciowego we współczesnych systemach Linux:

Kto jest odpowiedzialny za czytanie /etc/resolv.conf? Którzy gracze (usługi lub podsystemy jądra) są zaangażowani w rozpoznawanie nazw domen?

KRÓTKA ODPOWIEDŹ: Podręcznik Arch Linuxa mówi, że konfiguracja wysokiego poziomu rozpoznawania nazw domen została wykonana /etc/nsswitch.conf i opiera się na glibcinterfejsie API usługi Name Service Switch .

glibcużywa nss-resolvefunkcji do wysyłania żądań DNS do serwerów DNS.

Zwykle nowoczesne systemy CentOS nss-resolve polegają na systemd-resolved serwisie. Jeśli /etc/resolv.confzostał wygenerowany przez coś podobnego dhclient-script, systemd-resolvedczyta go i działa w trybie zgodności, emulując zachowanie starszych systemów, takich jak BINDklient DNS.

Biblioteki klienta DNS tak.

Biblioteki C zawierają klientów DNS, którzy zamykają wyszukiwanie nazw w adresach w protokole DNS i przekazują je serwerom proxy proxy, aby wykonać całą pomyłkę przy rozwiązywaniu zapytań. Istnieje wiele takich klientów DNS. Ta, która znajduje się w głównej bibliotece wykonawczej C twojego systemu operacyjnego, najprawdopodobniej będzie tą z BIND ISC. Ale istnieje cała masa innych, od dnsbiblioteki Daniela J. Bernsteina, poprzez cresy aż po adns.

Chociaż kilka z nich zawiera własne natywne mechanizmy konfiguracji, generalnie mają tryb zgodności biblioteki BIND, w którym czytają resolv.conf, czyli plik konfiguracyjny biblioteki klienta BIND C. ISC.

Na wierzchu jest NSS i jest skonfigurowany przez nsswitch.conf. Jedną z rzeczy, które mogą być wewnętrznie wywoływane przez wyszukiwania NSS, jest klient DNS i nsswitch.confjest on odczytywany przez kod NSS w bibliotece C w celu ustalenia, czy i gdzie są przekazywane wyszukiwania DNS i jak radzić sobie z różnymi odpowiedziami.

(Istnieje niewielka komplikacja tego pomysłu spowodowana przez pamięć podręczną usług nazw Dæmon, nscd. Ale to po prostu dodaje dodatkowego klienta wyższej warstwy w bibliotece C, mówiącego specyficzny protokół do lokalnego serwera, który z kolei działa jako Klient DNS mówiący protokołem DNS do serwera DNS proxy. systemd-resolvedPowoduje podobne komplikacje).

systemd-resolved, NetworkManager, connman, dhcpcd, resolvconf, I inne dostosować plik konfiguracyjny klienta DNS BIND DNS dla klientów przełącznik rozmawiać z różnymi serwerami DNS proxy w locie. Jest to poza zakresem tej odpowiedzi, zwłaszcza, że ​​na tej stronie WWW jest wiele odpowiedzi na temat bizantyjskich szczegółów, które obejmuje taki mechanizm.

Bardziej tradycyjnym sposobem robienia rzeczy w świecie uniksowym jest uruchamianie serwera proxy DNS na samym komputerze lub w sieci LAN. Stąd to, co mówi FreeBSD o normalnie skonfigurowanych systemach, w których domyślne działanie biblioteki klienta DNS przy braku zgodności resolv.confodpowiada temu, co normalnie mają administratorzy systemu Unix, czyli serwer proxy DNS nasłuchujący na 127.0.0.1. (Podręcznik FreeBSD dla resolv.conffaktycznie jest dokumentem, który również pochodzi z BIND ISC, i oczywiście można go również znaleźć tam, gdzie biblioteka klienta BIND DNS została włączona do innych miejsc, takich jak biblioteka GNU C.)

Dalsza lektura

• Daniel J. Bernstein. Biblioteka . cr.yp.to.dns
• Jonathan de Boyne Pollard (2017). Co to jest kwalifikacja nazwy DNS . Często udzielane odpowiedzi.
• Jonathan de Boyne Pollard (2004). Co to jest rozpoznawanie zapytań DNS . Często udzielane odpowiedzi.
• Jonathan de Boyne Pollard (2001). Wielki obraz dla „djbdns” . Często udzielane odpowiedzi.
• Jonathan de Boyne Pollard (2000). serwery DNS „content” i „proxy”. Często udzielane odpowiedzi.

Ze znacznie lepszej strony podręcznika 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.

Plik /etc/resolv.confjest odczytywany przez wywołania * libc, które wykonują rozpoznawanie nazw hostów. To jest przede wszystkimgetaddrinfo i przestarzałe gethostbyname.

Jeśli te funkcje otrzymają nazwę DNS, wówczas wykonują te czynności w następującej kolejności:

1. Spróbuj rozwiązać nazwę hosta lokalnie, czyli czytając /etc/hosts .
2. Jeśli to się nie powiedzie, zapytaj serwerów DNS wymienionych w /etc/resolv.conf .
3. Jeśli to również się nie powiedzie, nazwa hosta nie może zostać rozwiązana.

Ponieważ wspomniałeś o dnsmasq : jest to serwer DNS, który działa lokalnie. Tak więc, w wielu współczesnych dystrybucjach Linuksa, /etc/resolv.confjedyne punkty to 127.0.0.1(tutaj nasłuchuje lokalny dnsmasq). dnsmasq jest następnie skonfigurowany do przekazywania zapytań do serwerów DNS; dnsmasq jest konfigurowany przez Network Managera po podłączeniu do Internetu.