Czy VPN naprawił DNS, czy tylko ponownie użył odpowiedzi z pamięci podręcznej?

Otwarcie strony kilka sekund po podniesieniu tunelu nie jest dowodem, że DNS teraz działa, choć zgłoszenie zwykle tak twierdzi. Nic w tej obserwacji nie wymagało zapytania: nazwa mogła zostać rozwiązana przed zmianą i ponownie użyta z pamięci podręcznej, której tunel nigdy nie dotknął. Dwa różne testy dają ten sam ekran.

Porównaj, co każdy test faktycznie przećwiczył, zanim przypiszesz zmianie zasługę.

Ładowanie strony nie jest zapytaniem

Każda warstwa między aplikacją a resolverem może pamiętać odpowiedź przez cały okres swojego życia. System operacyjny trzyma jedną, przeglądarka trzyma własną, a aplikacja z długotrwałym połączeniem może już nigdy niczego nie rozwiązać w trakcie sesji. Udane ładowanie po zmianie tunelu może więc być demonstracją pamięci, a nie routingu. Brak błędu nie jest obecnością zapytania.

Ta różnica zmienia to, co powinieneś przetestować dalej. Jeśli celem jest pokazanie, że nowy resolver odpowiada, potrzebujesz zapytania, którego nie można obsłużyć z pamięci podręcznej, której nie wyczyściłeś.

Odczytanie sukcesu z pamięci podręcznej jako dowodu, że wcześniej niedostępny serwer się podniósł, jest najdroższą wersją tego błędu, ponieważ zamyka incydent na fałszywym założeniu.

Policz pamięci podręczne, zanim wyciągniesz wniosek

Cztery warto nazwać: własne rozwiązywanie aplikacji, pamięć podręczna klienta systemu operacyjnego, stan wewnętrzny przeglądarki i dowolny resolver rekurencyjny, do którego zapytanie w końcu dociera. Każda ma odrębny czas życia i odrębny sposób czyszczenia. Wyczyszczenie jednej i testowanie innej to sposób, w jaki ludzie dochodzą do wniosku, że czyszczenie nic nie dało. Jedno polecenie czyszczenia nigdy nie rozstrzyga sprawy.

Odpowiedzi negatywne też są buforowane. Nazwa zgłoszona jako brakująca może pozostać brakująca po naprawieniu sieci, co czyta się jako zepsuty tunel, gdy jest to TTL, który jeszcze nie wygasł. Specyfikacja DNS opisuje, jak te dane powinny być przechowywane i ponownie wykorzystywane.

Zapisz zdarzenie, nie wrażenie

Zapisz, która z trzech rzeczy się zmieniła: rekord, ścieżka do resolvera lub ustawienie klienta. Edycja rekordu rozprzestrzenia się według własnego harmonogramu, zmiana trasy działa przy ponownym połączeniu, a ustawienie przeglądarki dotyczy tylko tej przeglądarki. Złożenie ich w jedno przed-i-po tworzy oś czasu, której nikt nie może zweryfikować.

Zapisz czas, użyty resolver i otrzymaną odpowiedź, w tym przypadek, gdy odpowiedź jest negatywna. To fakt, który ktoś inny może sprawdzić.

Wykonaj porównanie dwa razy w ten sam sposób

Wyczyść pamięć podręczną, którą zamierzasz testować, zachowaj pierwotną obserwację, a następnie zapytaj w sposób, który omija jak najwięcej pamięci. Nazwanie resolvera wprost mówi, co ten resolver wie; nie mówi, który resolver wybrałaby aplikacja.

resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example

W Windows wyczyszczenie pamięci podręcznej klienta czyści pamięć podręczną klienta DNS i nic więcej. Nie opisuje prywatnego stanu przeglądarki i nie czyści serwera nadrzędnego, więc test na nim oparty można interpretować tylko wąsko. Za każdym razem, gdy zgłaszasz wynik, powiedz, którą pamięć podręczną wyczyściłeś.

Następnie ponownie przetestuj rzeczywistą aplikację ze świeżym żądaniem i aktywną zamierzoną polityką resolvera. Wynik uzyskany w innej polityce nie przenosi się.