Raport DNS przez VPN: co uwzględnić, aby dało się go odtworzyć

„DNS jest zepsuty” to wniosek, i nie jest to wniosek, na którym pomocnik może działać. Użyteczna część raportu to kształt awarii: która nazwa, przez który resolver, z jaką odpowiedzią. Trzy szczegóły zamieniają skargę w coś odtwarzalnego, a wszystkie trzy można bezpiecznie udostępnić po zmianie nazw prywatnych części. Poniżej znajduje się minimum, którego raport DNS przez VPN potrzebuje, zanim ktokolwiek może pomóc.

Kategoria nazwy, nie wyrok

Zacznij od samej nazwy i sklasyfikuj ją: publiczna, wewnętrzna, krótka, w pełni kwalifikowana albo obsługiwana przez jeden konkretny sufiks. Wewnętrzna nazwa, która zawodzi, gdy nazwy publiczne się rozwiązują, wskazuje na wybór resolvera, a nie na osiągalność. Jeśli zawodzą wszystkie nazwy, wskazuje to na ścieżkę do resolvera, a to inne dochodzenie z innymi dowodami. Kategoria niesie diagnozę, a dokładny ciąg można zamazać.

Powiedz, czy awaria wymaga podniesionego tunelu, czy następuje po jego rozłączeniu. Nazwa, która psuje się tylko przy aktywnym VPN, wskazuje na konfigurację dla każdego połączenia, a ta, która psuje się po rozłączeniu, na stan szczątkowy. Raporty zwykle to pomijają, a potem dziwią się, dlaczego pierwsza sugestia nie pomaga.

Zapisz ścieżkę resolvera

Zapytanie wysłane do jawnie wybranego serwera i zwykłe wyszukiwanie aplikacji to różne eksperymenty. Powiedz, które z nich spowodowało awarię, bo ręczne zapytanie do działającego serwera dowodzi tylko, że serwer działa. Poniższe polecenia oddzielają ścieżkę systemową od bezpośredniego pytania.

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

Wyjście statusu wymienia serwery dla każdego połączenia i domeny routingu, czyli gdzie decyduje się split DNS. Wywołanie getent podąża tą samą ścieżką co aplikacja, łącznie z kolejnością nsswitch. Bezpośrednie zapytanie omija oba i testuje jeden serwer w izolacji. Zgłoś, które z trzech zawiodło, a które się udało, a czytelnik nie musi już zgadywać ścieżki.

Podaj kontrolowane porównanie

Zmień jedną zmienną i powiedz, co się zmieniło. To, że nazwy publiczne się rozwiązują, a wewnętrzne zawodzą, to problem wyboru; to, że każda nazwa kończy się przekroczeniem czasu, to problem ścieżki; a prywatna nazwa rozwiązująca się na publiczny adres to wyciek do złego resolvera. Dwie z tych trzech rzeczy nie mają nic wspólnego z tym, czy tunel jest podniesiony. Raport twierdzący, że wszystkie zapytania są zepsute, zwykle zawiera porównanie, którego nigdy nie wykonano.

Oddziel rozwiązywanie od dostarczania. Gdy nazwa się rozwiązuje, a witryna nadal zawodzi, etap DNS się powiódł i raport powinien to powiedzieć, bo następnym krokiem jest trasa lub nasłuchiwacz, a nie resolver. To jedno rozróżnienie częściej oszczędza całą rundę pytań niż jakikolwiek fragment dziennika.

Zamaż przestrzeń nazw, zachowaj zależności

Wewnętrzne nazwy można zastąpić, o ile zamienniki zachowują strukturę. Przypisz każdy odrębny serwer i sufiks do stabilnej etykiety i trzymaj to mapowanie poza udostępnianą kopią. Zastąpienie każdego wewnętrznego hosta tym samym symbolem zastępczym niszczy dokładnie ten dowód, którego potrzebuje raport, bo czytelnik nie widzi już, że jeden sufiks się rozwiązał, a drugi nie. Ta sama zasada dotyczy adresów: zachowaj zależności prefiksów i zmień bity hosta, jeśli wymaga tego polityka.

Wyślij rekord zweryfikowanym kanałem i pomiń to, czego diagnoza nigdy nie potrzebuje. Hasła, klucze prywatne i niepowiązane nazwy firm nie są częścią pytania o DNS. Czytelnik potrzebuje kategorii awarii, ścieżki resolvera, dokładnego błędu i jednego porównania, które wykonałeś.