Jak skonfigurować systemd-resolved i systemd-networkd do korzystania z lokalnego serwera DNS do rozwiązywania domen lokalnych i zdalnego serwera DNS dla domen zdalnych?

Jestem połączony z siecią lokalną z dostępem do Internetu przez bramę. W sieci lokalnej znajduje się serwer DNS, który jest w stanie rozpoznać nazwy hostów komputerów z sieci lokalnej.

Chciałbym skonfigurować systemd-resolved i systemd-networkd, aby żądania wyszukiwania dla lokalnych nazw hostów były kierowane (kierowane) wyłącznie do lokalnego serwera DNS, a żądania wyszukiwania dla wszystkich innych nazw hostów byłyby kierowane wyłącznie do innego, zdalnego serwera DNS.

Załóżmy, że nie wiem, gdzie są pliki konfiguracyjne ani czy powinienem dodać więcej plików i wymagać podania ich ścieżek w odpowiedzi.

linux systemd dns systemd-networkd systemd-resolved Piotr Dobrogost
źródło

Odpowiedzi:

W pliku konfiguracyjnym interfejsu sieci lokalnej musimy albo określić, że chcemy uzyskać adres lokalnego serwera DNS z serwera DHCP, używając DHCP=opcji :

[Network]
DHCP=yes

lub wyraźnie podaj adres, używając DNS=opcji :

[Network]
DNS=10.0.0.1

Ponadto musimy określić (w tej samej sekcji) domeny lokalne za pomocą Domains=opcji

Domains=domainA.example domainB.example ~example

Określamy domeny lokalne, domainA.example domainB.exampleaby uzyskać następujące zachowanie (ze strony systemd-resolved.service, systemd-resolved man):

Wyszukiwanie nazwy hosta kończącej się na jednej z domen interfejsu jest kierowane wyłącznie do pasujących interfejsów.

Ten sposób hostX.domainA.examplezostanie rozwiązany wyłącznie przez nasz lokalny serwer DNS.

Podkreślamy, ~exampleże wszystkie domeny kończące się na examplemają być traktowane jako domeny tylko trasy, aby uzyskać następujące zachowanie (z opisu tego zatwierdzenia):

Serwery DNS, które mają domeny tylko trasy, powinny być używane tylko dla określonych domen.

Ten sposób hostY.on.the.internetzostanie rozwiązany wyłącznie przez nasz globalny, zdalny serwer DNS.

Uwaga

Idealnie, gdy używasz protokołu DHCP, lokalne nazwy domen powinny być uzyskiwane z serwera DHCP zamiast być wyraźnie określone w pliku konfiguracyjnym interfejsu sieciowego powyżej. Zobacz UseDomains=opcję . Jednak nadal występują nierozwiązane problemy z tą funkcją - zobacz problem opcji systemd-networkd domen wyszukiwania DHCP .

Musimy określić zdalny serwer DNS jako nasz globalny systemowy serwer DNS. Możemy to zrobić w /etc/systemd/resolved.confpliku:

[Resolve]
DNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844

Nie zapomnij ponownie załadować konfiguracji i zrestartować usługi:

$ sudo systemctl daemon-reload
$ sudo systemctl restart systemd-networkd
$ sudo systemctl restart systemd-resolved

Uwaga!

Powyższe gwarancje mają zastosowanie tylko wtedy, gdy nazwy są rozwiązywane przez systemd-resolved - patrz strona podręcznika dla nss-resolver , libnss_resolve.so.2 i strona podręcznika dla systemd-resolved.service, systemd-resolved .

Zobacz też:

Referencje:

Piotr Dobrogost
źródło

Czy rozważałeś nieużywanie .localw tym przykładzie? Z pewnością w przypadku avahi miało to być zarezerwowane dla MDNS, a nadużywanie tego było dużym nie-nie. Byłoby dla mnie łatwiejsze w użyciu example.comlub .przykład .

sourcejedi

@sourcejedi Dla odniesienia .localjest zdefiniowany jako domena specjalna w RFC 6762 - DNS multiemisji w sekcji Nazwy DNS multiemisji . Dzięki, naprawione.

Piotr Dobrogost

Niepowiązana uwaga: możesz także zaakceptować odpowiedzi.

intelfx

Myślę, że przydatne byłoby dodanie lokalizacji pliku konfiguracyjnego dla interfejsu sieci lokalnej . Nie masz pewności, czy to prawda /etc/systemd/network/*.network? Znaleziono tutaj superuser.com/a/1365864

Pierre Cordier

Zauważyłem, że ta odpowiedź „W pliku konfiguracyjnym ...” nie odpowiada na „PO Załóżmy, że nie wiem, gdzie znajdują się pliki konfiguracyjne ...” Jak ktoś, kto przybył tutaj w tym samym stanie niewiedzy o lokalizacja określonych plików konfiguracyjnych, odpowiedź jest niepełna.

Eric Towers

Aby rozwinąć doskonałą odpowiedź @piotrDobrogost, nie zapomnij o konfiguracji, /etc/nsswitch.confaby używać jej systemd-resolvedjako źródła rozpoznawania nazw DNS. Twój hostsdyrektywa powinna wyglądać następująco dla konkretnego przypadku użycia:

/etc/nsswitch.conf

hosts:  files resolve dns

Jeśli więc ograniczysz rozdzielczość tylko do domen określonych w Domainsdyrektywie w /etc/systemd/resolved.confpowyższym opisie Piotra, DNS należy następnie skonsultować w kolejności źródeł rozpoznawania nazw określonych, /etc/nsswitch.confgdy domeny NIE znajdują się w Domainsdyrektywie:

Poniższe odnośniki Link Wymóg określenia determinację w /etc/nsswitch.conftak systemd-resolvedjest konsultowany podczas rozpoznawania nazw:

https://github.com/systemd/systemd/issues/940

Dokumentacja SystemD okazała się tragiczna. Musiałem zebrać zrozumienie z wielu linków, w tym powyższej odpowiedzi Piotra ;-)

F1Linux
źródło

W przypadku korzystania z zalecanego trybu działania systemd-resolved, gdzie /etc/resolve.confznajduje się dowiązanie symboliczne do /run/systemd/resolve/stub-resolv.confpliku, które z kolei zawiera adres systemu rozpoznawania kodów pośredniczących DNS systemud- resolver, nie ma potrzeby umieszczania resolvedyrektywy w /etc/nsswitch.confpliku, ponieważ żądania DNS będą kierowane (ze względu na standardową nss-dnsdyrektywę) na przelicznik kodów pośredniczących, który działa zgodnie z regułami systemd-resolved .

Piotr Dobrogost

@PiotrDobrogost W jaki sposób można kontrolować źródła zamówień DNS są sprawdzane bez użycia /etc/nsswitch.conf``? In the specimen config above, / etc / hosts` (" pliki ") byłyby sprawdzane pod kątem statycznych adresów IP: mapowania nazw, a jeśli nie znaleziono, należy skonsultować się z rozwiązanym skrótem rozstrzygniętym . Nie rozumiem, w jaki sposób byłoby możliwe zebranie źródeł rozstrzygania DNS bez użycia /etc/nsswitch.conf. Czy brakuje mi tutaj podstępu?

F1Linux

Nie mówię, że nie /etc/nsswitch.confjest potrzebne. Mówię, że jeśli ktoś używa systemowego rozpoznawania nazw kodów DNS przez systemd-resolved, wystarczy mieć dnsdyrektywę na liście hosts:(prawdopodobnie po filedyrektywie). Nie ma potrzeby stosowania resolvedyrektywy tam jak to jest rezolwer stub że jest punktem wejścia do Systemd-rozdzielczej znajduje się logiką a nie nss-resolveplug-in module ...

Piotr Dobrogost

... Innymi słowy można reach Systemd-rozdzielczej na logikę albo poprzez resolvedyrektywa ➟ NSS-resolve NSS plug-in module ➟ Systemd-rozdzielczej lub za pośrednictwem dnsdyrektywy ➟ NSS-DNS plug-in NSS modułu ➟ Systemd-Rozwiązany'S 'rezolwerem stub DNS ➟ systemd-resolved

Piotr Dobrogost

@PiotrDobrogost myślę, że przybył na filesczym resolvethingy w /etc/nsswitch.confod 2 części pytania. Po ponownym przeczytaniu wygląda to tak, jakbyś właśnie mówił o sprawdzeniu lokalnej pamięci podręcznej pod kątem adresu IP: mapowanie nazwy, a następnie skontaktowanie się z usługą przesyłania dalej, jeśli nie zostanie znalezione. Zasadniczo ustawiam filespierwsze źródło rozdzielczości DNS tak, aby

pomijało