Dlaczego rozpoznawanie DNS działa na hoście, ale nie działa w kontenerze?

DNS na hoście może działać, podczas gdy DNS w kontenerze zawodzi, ponieważ kontener korzysta z innej ścieżki rozwiązywania nazw, przestrzeni nazw, trasy zapory sieciowej lub stanu przekierowania Docker.

Na serwerze domowym host może odpytywać bezpośrednio router, Pi-hole lub resolver VPN, podczas gdy kontener w sieci mostkowej wysyła żądania przez wbudowany resolver Dockera albo skopiowany plik resolv.conf. Najszybsza diagnoza polega na sprawdzeniu najpierw adresu IP, a następnie jawnym odpytywaniu każdego resolvera z poziomu kontenera, w którym występuje problem, aby nie pomylić awarii DNS z ogólnym brakiem łączności wychodzącej.

Oddziel awarię DNS od ogólnego problemu z siecią

Z poziomu kontenera, w którym występuje problem, sprawdź znany zewnętrzny adres IP oraz adres IP docelowego serwera DNS, zanim przetestujesz jakąkolwiek nazwę hosta. Zapisz trasy, utratę pakietów oraz to, czy port 53 jest osiągalny przez TCP i UDP.

Przypadek kontenera Manjaro pokazuje odwrotną sytuację: bezpośredni ruch IP również nie działał, co dowodziło, że problem wykraczał poza DNS. Ten test łączności z bezpośrednim adresem IP zapobiega maskowaniu uszkodzonej ścieżki mostka, NAT-u lub zapory przez zmiany resolvera.

Jeśli łączność IP nie działa, najpierw napraw sieć kontenera. Jeśli połączenia IP działają, ale nazwy nie są rozwiązywane, przejdź do konfiguracji resolvera i ścieżki zapytań.

Sprawdź konfigurację resolvera w kontenerze

Odczytaj plik /etc/resolv.conf w kontenerze i porównaj go z plikiem na hoście. Zwróć uwagę na adresy serwerów nazw, domeny wyszukiwania, opcje, tryb sieci oraz to, czy plik zmienia się po ponownym utworzeniu kontenera.

W przypadku OpenMediaVault zgłoszono, że wyszukiwanie nazw w kontenerach przestało działać przez wbudowany resolver Dockera 127.0.0.11 po aktualizacji środowiska uruchomieniowego. Ta ścieżka wbudowanego resolvera może działać inaczej niż poprawne rozwiązywanie nazw na hoście.

Nie edytuj trwale wygenerowanego pliku w działającym kontenerze. Skonfiguruj zamierzone serwery DNS i domeny wyszukiwania w konfiguracji Compose lub platformy, aby ustawienia przetrwały ponowne utworzenie kontenera.

Odpytuj osobno DNS Dockera i resolver nadrzędny

Wykonaj to samo zapytanie do wbudowanego resolvera Dockera, routera lub lokalnego serwera DNS oraz znanego zewnętrznego resolvera, jeśli zezwalają na to zasady sieciowe. Porównaj przekroczenie limitu czasu, odmowę, odpowiedź NXDOMAIN oraz zwrócony adres.

W przypadku omówionym przez społeczność TrueNAS przyczyną awarii DNS występującej wyłącznie w kontenerach był profil dostępu routera blokujący te żądania, mimo że inny ruch hosta działał poprawnie. Decydująca obserwacja dotyczyła zablokowanego DNS na ścieżce kontenera, a nie nieprawidłowej nazwy hosta.

Jeśli bezpośrednie zapytania do resolvera nadrzędnego działają, ale wbudowany resolver zawodzi, uruchom ponownie lub napraw resolver Dockera oraz stan sieci. Jeśli każdy serwer DNS przekracza limit czasu, sprawdź routing portu 53, zaporę, VPN oraz ruch z odpowiedziami.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Sprawdź lokalne pętle DNS i nieprawidłowe odpowiedzi wewnętrzne

Ustal, czy kontener próbuje odpytywać usługę DNS działającą na tym samym hoście, w innym kontenerze lub nazwę hosta, która jest ponownie rozwiązywana przez odwrotny proxy. Przechwyć odpowiedź zamiast zakładać, że każde udane rozwiązanie nazwy jest poprawne.

W przypadku omówionym przez społeczność Traefik ustalono, że jeden kontener rozwiązywał niestandardową domenę do samego siebie zamiast do zamierzonego kontenera równorzędnego. Ta nieprawidłowa odpowiedź DNS po stronie kontenera przechodziła podstawowy test rozwiązywania nazw, ale nadal uniemożliwiała połączenie z API.

Do ruchu między kontenerami w tej samej sieci używaj nazw usług, a split DNS dla publicznych nazw hostów stosuj tylko wtedy, gdy ścieżka powrotna jest zamierzona. Unikaj tras hairpin, które wysyłają kontener przez publiczny proxy, aby dotrzeć do lokalnej zależności, chyba że ta ścieżka została wyraźnie przetestowana.

Zweryfikuj odpowiedzi UDP, NAT i izolację sieci

Przechwyć ruch na porcie 53 na interfejsie kontenera i moście hosta. Potwierdź, że zapytanie opuszcza kontener, resolver je otrzymuje, a odpowiedź wraca z adresu, którego oczekuje klient.

Użytkownicy Pi-hole opisywali przypadki, w których zapytania między kontenerami na tym samym hoście przekraczały limit czasu, ponieważ odpowiedzi wracały z nieoczekiwanego, przetłumaczonego adresu źródłowego. Ten nieoczekiwany adres źródłowy odpowiedzi DNS pozwala odróżnić problem ze ścieżką odpowiedzi od nieaktywnego resolvera.

Jeśli żądanie i odpowiedź przechodzą przez różne sieci Dockera, dodaj właściwą współdzieloną sieć lub trasę zamiast przenosić wszystkie usługi do sieci hosta. Sprawdź strefy zapory i zasady VPN, które mogą traktować podsieci mostkowe inaczej niż adres hosta.

Odtwórz stan sieci i potwierdź rozwiązanie problemu

Po skorygowaniu resolvera, zapory lub definicji sieci utwórz ponownie jeden testowy kontener w zamierzonej sieci i powtórz testy adresu IP, bezpośredniego resolvera, wbudowanego resolvera, nazwy usługi oraz nazwy publicznej.

Poradnik ZimaSpace dotyczący oddzielania awarii adresu od awarii nazwy wyznacza powiązaną granicę diagnostyki po stronie hosta.

Problem jest rozwiązany dopiero wtedy, gdy konfiguracja DNS przetrwa ponowne utworzenie kontenera i ponowne uruchomienie systemu, wewnętrzne nazwy usług oraz zatwierdzone nazwy publiczne zwracają właściwe adresy, a ruch aplikacji działa tą samą ścieżką sieciową. Jeśli problem powraca dopiero po aktualizacji Dockera, zachowaj wersję oraz logi demona jako punkt odniesienia dla regresji środowiska uruchomieniowego.