Testowanie dzielonego DNS bez wycieku nazw wewnętrznych

Odpytanie publicznego resolvera o nazwę wewnętrzną ujawnia ją i pomija regułę, którą chciałeś przetestować. Zapytanie dociera do serwera, którego nie kontrolujesz, odpowiedź pochodzi z przestrzeni nazw, która nie powinna była jej widzieć, a wynik nie mówi nic o tym, czy dzielony DNS działa. Testowanie dzielonego DNS oznacza testowanie ścieżki resolvera, której aplikacja faktycznie używa. Tę ścieżkę wybiera system operacyjny, lista domen w profilu VPN, a czasem przeglądarka.

Wybierz dwie nazwy i najpierw przewidź obie odpowiedzi

Poproś właściciela sieci o jedną udokumentowaną wewnętrzną nazwę testową i wybierz zwykłą nazwę publiczną, która nic nie mówi o organizacji. Zanim cokolwiek uruchomisz, zapisz, co powinno się stać w każdym przypadku: nazwa wewnętrzna powinna dotrzeć do resolvera tunelu i zwrócić adres wewnętrzny, a nazwa publiczna powinna zostać rozwiązana przez resolver, którego system zwykle używa. Te dwa przewidywania są testem, bo bez nich każdą odpowiedź można uzasadnić po fakcie. Utrzymuj parę stałą między uruchomieniami, aby późniejsze porównanie coś znaczyło.

Sprawdzaj reguły faktyczne, a nie zamierzone. Lista domen dołączona do połączenia VPN decyduje, które sufiksy trafiają do którego resolvera, a literówka w tej liście daje wiarygodny, ale błędny podział. Na zarządzanym urządzeniu użyj ścieżki diagnostycznej administratora, ponieważ lokalne nadpisania mogą zostać zresetowane przez politykę przy następnym sprawdzeniu.

Zapisz przewidywanie obok zaobserwowanej odpowiedzi w tym samym zgłoszeniu. Test bez przewidywania nie może się nie udać, a test, który nie może się nie udać, niczego nie uczy.

Testuj ścieżkę używaną przez aplikację, a nie jeden wybrany przez siebie serwer

Polecenie, które wprost nazywa resolver, testuje tylko ten resolver i nic więcej. Mówi, czy serwer wewnętrzny odpowiada, co jest przydatne, ale nie mówi, czy aplikacja wysyła tam nazwę. Najpierw testuj normalną ścieżką: rozwiąż nazwę wewnętrzną tak, jak zrobiłaby to aplikacja, a następnie w ten sam sposób rozwiąż nazwę publiczną. Dopiero potem pytaj konkretne serwery, aby znaleźć, gdzie zachowanie się rozchodzi.

Przeglądarki komplikują obraz, ponieważ ustawienia bezpiecznego DNS mogą całkowicie ominąć resolver systemowy. Przeglądarka skonfigurowana z własnym szyfrowanym resolverem nigdy nie widzi podziału, a awaria wygląda jak zepsuty profil VPN. Sprawdź to ustawienie, zanim zmienisz tunel.

Powtórz wyszukiwanie po ponownym połączeniu, jeśli pytanie dotyczy przywrócenia. Odpowiedź z pamięci podręcznej z czasów przed ponownym połączeniem może sprawić, że poprawnie przywrócony podział wygląda lepiej lub gorzej, niż jest.

Zapisuj kategorię odpowiedzi, nie tylko sukces lub porażkę

Zapisz, które z czterech rzeczy nastąpiły: adres wewnętrzny, adres publiczny, odpowiedź negatywna lub przekroczenie czasu. Każda ma inne znaczenie. Adres wewnętrzny dla nazwy wewnętrznej to oczekiwany sukces; adres publiczny dla nazwy wewnętrznej sugeruje, że zapytanie opuściło tunel; odpowiedź negatywna od serwera autorytatywnego wskazuje na brakujący rekord, a nie na błąd routingu; a przekroczenie czasu wskazuje na problem z osiągalnością lub resolver, który nigdy nie otrzymał zapytania. Sukces i porażka są zbyt grube, by na nich działać.

Uwzględnij pamięć podręczną, zanim zinterpretujesz brak świeżego zapytania, ponieważ negatywna odpowiedź w pamięci podręcznej wygląda identycznie jak nieistniejąca nazwa. Zapisz odpowiedź, zanim cokolwiek wyczyścisz obsługiwanymi narzędziami, ponieważ pierwsza odpowiedź jest dowodem.

Interpretuj obie gałęzie bez zgadywania

Jeśli nazwa wewnętrzna rozwiązuje się poprawnie, a aplikacja nadal zawodzi, resolver wykonał swoją pracę, a kolejnymi podejrzanymi są trasy i uprawnienia na samym zasobie. Jeśli nazwa prywatna dotarła do publicznego resolvera, reguła podziału nie jest stosowana do tego wyszukiwania, więc przejrzyj listę domen i wszelką politykę przeglądarki wraz z właścicielem przestrzeni nazw. Te dwie gałęzie mają różnych właścicieli, dlatego ważniejsze jest zapisanie, którą widziałeś, niż zapisanie, że coś się zepsuło.

Zredaguj współdzielone wyjście, zachowując strukturę: która przestrzeń nazw, która reguła, która kategoria odpowiedzi. Odpowiedź resolvera może zawierać adresy wewnętrzne i nazwy hostów, a zgłoszenie jest trwałym domem dla obu.

Następnie przekaż wynik właścicielowi przestrzeni nazw z dwiema zaobserwowanymi kategoriami i usuniętymi nazwami. To pięciominutowa rozmowa zamiast tygodnia spekulacji.