Co powoduje przerywane błędy DNS w aplikacjach hostowanych samodzielnie?

Przerywane błędy DNS występują, gdy ścieżka rozwiązywania nazw aplikacji zmienia się, przekracza limit czasu, jest przeciążona lub zwraca niespójne odpowiedzi z pamięci podręcznej.

W samodzielnie hostowanym stosie nieudane zapytanie może przechodzić przez środowisko uruchomieniowe aplikacji, kontenerowy stub DNS, resolver hosta, router, Pi-hole lub AdGuard Home, politykę VPN oraz nadrzędny serwer publiczny lub autorytatywny. Test przeglądarki z poziomu hosta nie może udowodnić, że aplikacja widzi tę samą ścieżkę, więc diagnoza musi przechwycić nieudane zapytanie wewnątrz dotkniętego kontenera lub usługi i porównać je z udanym zapytaniem w tym samym momencie.

Przechwyć nieudane zapytanie wewnątrz dotkniętego środowiska aplikacji

Zapisz dokładną nazwę hosta, tekst błędu, znacznik czasu, kontener lub proces oraz czy błąd dotyczy nazw wewnętrznych, publicznych, czy obu. Wykonuj powtarzane zapytania z wnętrza dotkniętego środowiska zamiast polegać wyłącznie na testach na poziomie hosta.

Problem Kubernetes opisuje przerywane błędy, gdzie pierwsze zapytanie DNS przekroczyło limit czasu, podczas gdy późniejsze zapytania zakończyły się sukcesem. Ten wzorzec pokazuje, dlaczego jedno udane zapytanie po incydencie nie wyjaśnia przejściowej awarii resolvera.

Zaloguj czas trwania zapytania, zwrócony serwer, kod odpowiedzi i wynik ponowienia. Jeśli zawodzi tylko jedna nazwa, sprawdź tę strefę lub autorytet; jeśli zawodzi każda nazwa, skup się na lokalnym stubie, nadrzędnym resolverze lub ścieżce sieciowej.

Porównaj DNS hosta z DNS kontenera lub usługi

Sprawdź konfigurację resolvera wewnątrz kontenera, maszyny wirtualnej lub piaskownicy aplikacji i porównaj ją z aktywnymi serwerami DNS hosta. Środowiska uruchomieniowe kontenerów mogą dostarczać wbudowany stub lub kopiować wygenerowany resolv.conf zamiast bezpośrednio udostępniać resolver hosta.

Przypadek społeczności HashiCorp pokazał, że DNS działa na hoście, ale nie w kontenerze, ponieważ nasłuchiwacz systemd-resolved hosta nie był dostępny z mostu, co wymagało dodatkowego nasłuchiwacza resolvera na adresie, który kontener mógł zapytać.

Zapytaj skonfigurowany serwer nazw bezpośrednio z obu środowisk. Jeśli host odnosi sukces, a kontener przekracza limit czasu wobec loopback lub niedostępnego stuba, napraw ścieżkę resolvera widoczną z mostu zamiast wielokrotnie restartować aplikację.

Oddziel awarie stref wewnętrznych od awarii publicznego DNS

Przetestuj jedną stabilną nazwę publiczną i jedną wymaganą nazwę usługi wewnętrznej podczas tego samego okna awarii. Awaria tylko wewnętrzna wskazuje na split DNS, domeny wyszukiwania, lokalne rekordy autorytatywne lub warunkowe przekazywanie; awaria obu wskazuje na ścieżkę rekurencyjną.

Raport z forum Docker opisuje DNS, który powinien rozwiązywać się konsekwentnie, ale zawodził bez wyraźnego wzorca podczas budowania. DNS kontenera może więc zawodzić nawet gdy sieć aplikacji pozostaje dostępna.

Jeśli nazwy publiczne działają, a nazwa aplikacji wewnętrznej zawodzi, zapytaj lokalny serwer autorytatywny bezpośrednio i użyj pełnej domeny zamiast krótkiej nazwy z sufiksem wyszukiwania. Jeśli oba zawiodą, tymczasowo ominięcie lokalnego filtra jednym znanym resolverem pozwoli ustalić, czy błąd leży u źródła czy w sieci domowej.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Zmierz limity czasu resolvera, obciążenie i zachowanie UDP względem TCP

Wykonuj powtarzane zapytania z pomiarem czasu bezpośrednio do każdego resolvera w łańcuchu i porównuj UDP z TCP. Śledź utratę pakietów, czas odpowiedzi, SERVFAIL, przekroczenie limitu czasu, obcięcie oraz czy awarie pokrywają się z zadaniami zapasowymi, aktualizacjami filtrów lub wysokim użyciem CPU.

Przewodnik po rozwiązywaniu problemów z przerywanym DNS zaleca przechwytywanie awarii w momencie ich wystąpienia i oddzielanie niestabilności resolvera od utraty sieci zamiast zmieniać kilka serwerów DNS jednocześnie.

Jeśli jeden resolver przekracza limit czasu, a inny odpowiada natychmiast, utrzymaj stałą ścieżkę aplikacji i wymień lub napraw awaryjny resolver. Jeśli wszystkie resolvery zawodzą jednocześnie z kontenera, ale nie z hosta, wróć do analizy mostu, zapory, conntrack i zachowania przestrzeni nazw.

Sprawdź odnowienia DHCP, polityki VPN i zmiany resolvera w czasie

Porównaj konfigurację DNS przed i po odnowieniu DHCP, zmianach połączenia VPN, uśpieniu hosta, restarcie routera lub odtworzeniu kontenera. Przerywane awarie często następują po zdarzeniu cyklu życia, które cicho zastępuje resolver lub domenę wyszukiwania.

Użytkownik Docker zlokalizował jeden pozornie losowy problem do odnowienia dzierżawy DHCP, a inny do interakcji między Dockerem a Tailscale. Tego rodzaju dowody czasowe są silniejsze niż założenie, że resolver zawodzi losowo.

Zapisz listę resolverów, trasy, domeny wyszukiwania i stan VPN przed i po zdarzeniu. Napraw źródło, które je nadpisuje — DHCP, NetworkManager, systemd-resolved, klient VPN lub środowisko uruchomieniowe kontenera — zamiast na stałe ustawiać publiczny resolver, który nie odpowiada na nazwy wewnętrzne.

Zweryfikuj naprawę przez oryginalne okno awarii

Uruchom zaplanowane zapytanie z wnętrza środowiska aplikacji przez dłuższy czas niż interwał, który zwykle powoduje awarie. Zaloguj używany resolver, opóźnienie, kod odpowiedzi i wynik na poziomie aplikacji zamiast rejestrować tylko udane zapytania z linii poleceń.

Przewodnik ZimaSpace dotyczący niekonsekwentnego rozwiązywania nazw NAS obejmuje powiązany problem po stronie klienta; ten test skupiony na aplikacji musi dodatkowo udowodnić, że kontener i środowisko uruchomieniowe stale używają zamierzonego resolvera.

Problem jest rozwiązany tylko wtedy, gdy oryginalna operacja aplikacji zakończy się pomyślnie przez restarty routera, odnowienia dzierżawy, odtworzenie kontenera i zmiany stanu VPN, które wcześniej wywoływały awarię. Jeśli restarty jedynie resetują licznik czasu, kontynuuj zbieranie stanu w momencie awarii zamiast akceptować restart jako naprawę.