NXDOMAIN przez VPN nie oznacza awarii tunelu

Kuszące jest odczytanie jednego nieudanego zapytania jako dowodu, że tunel się zawalił, zwłaszcza gdy nazwa działała dziesięć minut wcześniej. Odpowiedź mówi co innego. NXDOMAIN to zakończona transakcja DNS, w której resolver oświadczył, że pytana nazwa nie istnieje; zepsuty tunel zwykle daje ciszę, przekroczenie czasu lub próbę rozwiązywania wobec niewłaściwego serwera. Wersja argumentu bez wiresharka to jedno zapytanie, jeden odpowiadający i jeden kod odpowiedzi, i tę trójkę warto zapisać przed jakimikolwiek zmianami konfiguracji.

Co odpowiedź faktycznie ustala

DNS rozdziela wyniki, które klienci często zlewają w jedną awarię. Nieistniejąca nazwa daje odpowiedź negatywną z kodem NXDOMAIN, podczas gdy nazwa istniejąca, ale bez rekordu żądanego typu, daje odpowiedź udaną z pustą sekcją odpowiedzi. Oba wyglądają dla aplikacji jak nic użytecznego, i tylko jeden z nich oznacza, że nazwa jest błędna.

Ta różnica decyduje, gdzie należy naprawa. Brakujący rekord AAAA na hoście, który ma rekord A, nie jest brakującym hostem, a ponowne wydanie certyfikatu lub odbudowa tunelu w pogoni za tym marnuje jedyną dostępną wskazówkę. Różnica określa też kształt dalszych działań: problem nazewnictwa naprawia się w strefie, a problem typu naprawia się, prosząc o właściwy rekord lub akceptując, że rodzina adresów po prostu nie występuje.

Mit: brak prywatnej nazwy oznacza, że tunel zawiódł

Mit trwa, ponieważ te dwa zdarzenia tak często przychodzą razem. Klient łączy się z VPN, system operacyjny zachowuje resolver, któremu już ufał, a wewnętrzna nazwa, której teraz potrzebuje, jest pytana u serwera, który nigdy nie słyszał o strefie prywatnej. Ten serwer odpowiada uczciwie i negatywnie. Tunel niesie pakiet; odpowiedź dotyczy po prostu przestrzeni nazw, której odpowiadający nie obsługuje.

Układy split-horizon czynią to rutyną: ta sama nazwa strefy istnieje publicznie i wewnętrznie z różną zawartością, a prywatne rekordy zna tylko wewnętrzny resolver. Uzyskanie negatywnej odpowiedzi, która wygląda autorytatywnie, jest więc dowodem na to, który resolver odpowiedział, a nie dowodem stanu interfejsu.

Wynik rozstrzygają dwa szczegóły konfiguracji. Tunel musi wypchnąć lub wybrać wewnętrzny resolver, a klient musi zastosować ten wybór do pytanej nazwy. Reguła dla domeny, która nazywa sufiks nieco inny niż wpisany rekord, wyśle zapytanie publiczną ścieżką, a odpowiedź będzie poprawna i bezużyteczna.

Pytaj właściwego resolvera pod właściwą nazwą

Zapisz odpowiadającego, zanim zapiszesz werdykt. Zapytanie, które nie pokazuje, który serwer odpowiedział, nie potrafi odróżnić problemu polityki od problemu przestrzeni nazw, a oba mają niepowiązane poprawki.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

Pierwsze dwie linie pokazują, co zdecydował lokalny resolver i kogo by zapytał. Zapytanie +search odtwarza to, co robi aplikacja, gdy dodaje sufiks wyszukiwania, co często jest prawdziwym zapytaniem, a nie tym wpisanym w narzędzie diagnostyczne. Ostatnia linia pyta wewnętrzny serwer bezpośrednio, omijając politykę klienta; jeśli to się udaje, podczas gdy zwykłe zapytanie zawodzi, strefa jest w porządku, a trasowanie zapytań nie.

Negatywne buforowanie wyjaśnia opóźnienie po poprawce

Odpowiedzi negatywne są buforowane z założenia, a RFC 2308 opisuje, jak czas życia negatywnego bufora wynika z rekordu autorytetu strefy. Poprawienie rekordu lub reguły resolvera nie gwarantuje więc natychmiastowej zmiany u klienta, a ponawianie zapytania, które wciąż zwraca buforowaną odpowiedź, niczego nowego nie dowodzi. Tylko inny odpowiadający, inna nazwa lub opróżniony bufor dają świeże dowody.

Wyczyść lokalny bufor, a następnie powtórz to samo zapytanie wobec tego samego odpowiadającego. W systemach korzystających z lokalnej usługi resolvera to jedna komenda; w innych to restart usługi lub narzędzie platformy, a konkretne narzędzie ma mniejsze znaczenie niż powtórzenie potem identycznego testu.

Oddziel nazwę od ścieżki

Gdy nazwa rozwiąże się na oczekiwany prywatny adres, DNS jako temat się kończy i następnym pytaniem staje się ścieżka aplikacji. Host, który odpowiada na zapytania, ale odmawia połączenia, ma inny problem, a dalsze dostrajanie resolverów po poprawnej odpowiedzi jest sposobem, w jaki incydent zyskuje trzy niepowiązane zmiany. Porównaj rozwiązany adres z tym, na którym usługa faktycznie nasłuchuje, zanim uznasz, że oba się zgadzają.

Zachowaj zapis: zapytanie, odpowiadającego, kod i rozwiązany adres. Ten zapis jest też tym, co czyni późniejszy raport weryfikowalnym, i jest różnicą między diagnozą a opowieścią o tunelu, który wydawał się wolny.