Śledź zapytanie DNS krok po kroku, aby znaleźć prawdziwe źródło
Narzucony adres resolvera nie decyduje o tym, jakie źródło widzi resolver. Prześledź klienta, forwarder i serwer odbierający, a potem zapisz ścieżkę.
Podanie klientowi adresu resolvera ustala, dokąd trafiają zapytania, a nie jakie źródło zobaczy resolver. Routing, przekazywanie i translacja mają swoje kolejne etapy między dwoma końcami. Instrukcja postępowania w pytaniach o źródło śledzi zapytanie krok po kroku i zapisuje, co faktycznie zobaczył każdy obserwator. Kolejność ma znaczenie, bo twierdzenie postawione przed obserwacją to tylko domysł w lepszym formacie.
Zapisz układ, zanim zaczniesz zbierać dowody
Cztery miejsca mogą powiedzieć ci coś o źródle DNS i nie wszystkie mówią to samo. Jądro klienta wie, jakiego źródła by użyło, forwarder wie, co wysłał w górę, urządzenie tłumaczące wie, co przepisało, a resolver odbierający wie, co dotarło. Zapisz, do których z nich faktycznie dotrzesz, zanim cokolwiek zbierzesz.
| Observation point | What it can prove | What it cannot prove | How to read it |
|---|---|---|---|
| client kernel | which source address it would use for that resolver | anything a device in between rewrote | ip route get against the resolver address |
| forwarder | that it sent an upstream query, and from which source | what the client originally asked for | its own log and its cache state |
| translating device | that a source was rewritten, and to what | whether the query was legitimate | NAT policy and its counters |
| receiving resolver | the address that actually arrived | which client behind that address asked | a scoped capture on port 53 |
Zapisz też swoje oczekiwanie, wraz z resolverem, o którym sądzisz, że jest w użyciu. Trasa dzielona może wysłać zapytanie zupełnie gdzie indziej, a pamięć podręczna może odpowiedzieć bez żadnej wymiany w górę, więc założenie trzymane tylko w pamięci nie przetrwa pierwszej niespodzianki. Trzymaj zadeklarowany projekt i zaobserwowaną ścieżkę w osobnych kolumnach tej samej notatki; gdy te dwie rzeczy się nie zgadzają, znalazłeś pytanie warte śledzenia.
Sprawdź, który proces faktycznie wysłał zapytanie
Zacznij od klienta: zapisz adres resolvera, nazwę zapytania i czas, a potem potwierdź, który proces je wysłał. Pierwsza linia poniżej nazywa proces trzymający gniazdo UDP i to jest sprawdzenie, które obiecuje ten nagłówek. Jeśli tym procesem jest pomocnik przeglądarki lub środowisko uruchomieniowe kontenera zamiast resolvera systemowego, reszta śladu opisuje ścieżkę, o którą nikt nie prosił.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Na hoście z kilkoma interfejsami ustal, jaki adres źródłowy wybiera jądro dla tego celu, zanim spojrzysz gdziekolwiek indziej. To ostatni punkt, w którym ścieżka jest w pełni pod twoją kontrolą, i to wartość, którą porównasz z tym, co zgłasza resolver. Rozbieżność jest sygnałem, że coś pośrodku przepisało pakiet albo że wysłano dwa różne zapytania.
Trzymaj nazwy testowe wewnętrzne, bo nazwa wewnętrzna wysłana do publicznego resolvera niczego nie dowodzi o ścieżce wewnętrznej i publikuje nazwę, której nie musiałeś publikować. Przeglądarka z włączonym bezpiecznym DNS w ogóle nie pojawi się na tej liście gniazd, a ta nieobecność sama jest odpowiedzią.
Forwarder wykonuje drugie, osobne zapytanie
Forwarder zamienia jedną wymianę na dwie. Żądanie schodzi w dół, a następnie forwarder wysyła własne zapytanie w górę z adresu, który wybiera. To jego konfiguracja, a nie klient, decyduje, co widzi resolver w górze.
Podręcznik dnsmasq wart jest lektury z tego powodu: dokumentuje, jak forwarder wybiera serwery w górze i wiąże swoją stronę nasłuchu, a nic w tym układzie nie przenosi źródła klienta w górę. Dziennik resolvera pokazujący adres bramy jest więc normalny, a nie dowodem usterki. Nieobecność równie łatwo odczytać błędnie, bo trafienie w pamięci podręcznej nie tworzy żadnego zapytania w górę i wygląda identycznie jak zapytanie, które nigdy nie dotarło. Przeczytaj konfigurację forwardera i stan jego pamięci podręcznej, zanim wyciągniesz którykolwiek z tych dwóch wniosków. Dwa pytania, dwa miejsca do sprawdzenia.
Odczytaj źródło na resolverze odbierającym
Jedyna obserwacja, która to rozstrzyga, jest wykonywana po stronie serwera. Wszystko, co wywnioskowano z listy interfejsów klienta, pozostaje hipotezą, dopóki resolver nie zgłosi, co faktycznie dotarło.
tcpdump -ni any port 53 and host 10.20.30.53Przechwyć na hoście resolvera, utrzymaj przechwycenie krótkie i ograniczone, i przechowaj je tam, gdzie pozwala polityka. Jeśli zaobserwowane źródło jest adresem przetłumaczonym, następne pytanie brzmi, które urządzenie wykonało translację i czy jego polityka jest tą zamierzoną. Przechwycenie odpowiada, co dotarło; nie wyjaśnia, dlaczego polityka na to pozwoliła. Nazwij obserwatora i etap w notatce, bo twierdzenie o prywatności dotyczące bramy dotyczy tego etapu, a nie całej ścieżki.
Zapisz ustalenie jako ścieżkę, nie jako adres
Zapisz klienta, resolver, każdego forwardera, zaobserwowane źródło na każdym etapie i politykę, która nim rządzi. Taki zapis odpowiada na większość przyszłych pytań bez kolejnego przechwycenia. Narysuj go jako łańcuch, bo lista adresów ukrywa, który etap dał który.
Dołącz datę, wersję klienta i rewizję konfiguracji do rysunku, aby późniejszy czytelnik mógł stwierdzić, czy nadal obowiązuje. Oddziel źródło transportowe od wszystkiego innego, co przetwarza usługa, bo widok adresu bramy nic nie mówi o tym, co jeszcze jest przechowywane. Także lokalizacja resolvera nic nie mówi o tym, który klient pytał. Trzymanie tych twierdzeń osobno jest tym, co czyni wniosek obronnym podczas przeglądu.