Kto obsługuje 1.1.1.1? Sprawdzanie adresu DNS, zanim mu zaufasz

Wkleiłeś 1.1.1.1 w pole DNS VPN-a, strona się wczytała, a poradnik wygląda teraz na potwierdzony. Ta obserwacja jest węższa, niż się wydaje: aplikacja zachowała się inaczej, a zmiana na razie nic nie mówi o tym, kto odpowiedział na zapytanie ani dlaczego stary układ zawiódł. Skopiowany poradnik często nazywa znany publiczny adres „DNS-em VPN-a”, co jest twierdzeniem o własności, a nie o osiągalności. Sprawdzenie, co reprezentuje adres, zajmuje pięć minut i zapobiega trwałej zmianie dokonanej z niewłaściwego powodu.

Działające ustawienie to nie tożsamość

Adres w polu ustawień jest punktem końcowym, a punkt końcowy ma operatora. Te dwa fakty są osobne, a drugi jest tym, który ludzie pomijają. Dla najczęściej kopiowanej pary odpowiedź jest publiczna: Cloudflare publikuje 1.1.1.1 i 1.0.0.1 jako adresy swojego resolvera i wymienia je w swoim oficjalnym wykazie adresów. Dlatego nazwa operatora należy obok adresu, a nie do osobnego poradnika.

Wpisanie tej pary przy aktywnym tunelu nie czyni firmy VPN jej operatorem i nie czyni ruchu anonimowym. Zapytanie opuszcza twój komputer w stronę firmy, która publikuje zakres adresów, a ta firma może być renomowana i mimo to nie być stroną, którą sugerował poradnik. Etykieta w instrukcjach i rzeczywisty operator to dwa różne twierdzenia. Żadne z nich nie mówi, kto obsługuje pośrednią ścieżkę sieciową.

Użyj własnego opublikowanego wykazu resolvera, aby potwierdzić parę adresów lub szyfrowany punkt końcowy. Rekomendacja innego dostawcy może być uzasadniona, a „polecany przez”, „osiągany przez” i „obsługiwany przez” nadal opisują trzy różne relacje.

Porównaj trzy rzeczy, których potrzebuje wpis

Wpis gotowy do przeglądu rozdziela trzy pytania: kto ma odebrać zapytanie, czy wymiana jest jawna czy szyfrowana oraz która ścieżka ma ją nieść. Nazwa dostawcy nie wypełni drugiego ani trzeciego, a etykieta kraju nie wypełni żadnego z nich. Zapisz trzy pozycje przed zmianą i porównaj je potem. Te pozycje nie są wymienne, a traktowanie ich jako jednej to sposób, w jaki przypuszczenie staje się dokumentacją.

To porównanie zamienia działające ustawienie w udokumentowaną decyzję. Bez niego następna osoba dziedziczy adres bez żadnego powodu. Najpierw przeczytaj trzecią kolumnę tabeli poniżej, bo właśnie tam w rzeczywistości kończy się większość pewnych siebie wyjaśnień.

Tabela jest celowo krótka. Chodzi o to, że każda pozycja odpowiada na inne pytanie i żadne pojedyncze pole nie wypełnia wszystkich trzech.

Lokalny przekazujący ukrywa prawdziwe źródło

Urządzenie skonfigurowane tak, by używać routera jako DNS, wskazuje na przekazujący. Ten adres wskazuje następnego odbiorcę zapytania, a nie resolver, który ostatecznie na nie odpowiada. Lokalny resolver stub dodaje ten sam dodatkowy krok, i łatwo go pomylić z prawdziwą rzeczą, bo pojawia się w każdym wyjściu statusu.

Stub przekazuje do źródeł, które to samo wyjście również wymienia, zwykle niżej. Przeczytaj cały łańcuch, zanim cokolwiek wywnioskujesz o operatorze, bo pierwsza linia nie jest całą odpowiedzią. W przeciwnym razie nazywasz recepcję firmą.

resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'

Drugie polecenie używa nazwy echa resolvera, gdy operator ją publikuje, aby zgłosić widziany adres źródłowy. Trzecie wskazuje serwer, który odpowiedział, a to często nie jest adres, który skonfigurowałeś. Porównaj wszystkie trzy wyjścia, zanim zapiszesz operatora.

Szyfrowany DNS zmienia to, co jest widoczne, a nie to, kto to widzi

DNS over HTTPS i DNS over TLS chronią wymianę między klientem a resolverem. Resolver nadal czyta każdą nazwę, o którą jest pytany, bo odpowiadanie jest jego zadaniem. Zmienia się to, kto może obserwować wymianę: sieć lokalna widzi połączenie z jednym punktem końcowym zamiast strumienia zapytań w czystym tekście.

Nie zmienia się relacja zaufania, która nadal wskazuje organizację obsługującą ten punkt końcowy. Przeglądarka z własnym ustawieniem bezpiecznego DNS może całkowicie ominąć resolver systemu operacyjnego. Traktuj je jako dwie konfiguracje, które mogą się nie zgadzać, a nie jako jedno ustawienie zastosowane dwa razy.

Nazwy prywatne znów potrzebują własnej decyzji. Tunel służbowy może kierować wybrane domeny do resolverów organizacji, a zastąpienie go usługą publiczną może zepsuć wewnętrzne wyszukiwania lub ujawnić nazwy wewnętrzne niewłaściwej stronie. Sprawdź politykę domen, zanim zastąpisz ustawienia całego adaptera.

Utrzymuj obserwację wąską

Porównując, zachowaj starą konfigurację i zmieniaj jedno ustawienie naraz. Zapisz aplikację, operację, politykę resolvera oraz to, czy nazwy publiczne i dozwolone prywatne nadal się rozwiązują po ponownym połączeniu. Porównanie z dwiema zmianami nie dowodzi żadnej z nich. Zapisz wynik tam, gdzie znajdzie go następna osoba, obok samego ustawienia.

resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.com

Jeśli aplikacja zacznie działać, trzymaj twierdzenie tak małe, jak pozwalają dowody. Ta zmiana pomogła jednemu testowi i nie mówi nic o tym, czy poprzedni resolver działał w złej wierze, czy tunel był zepsuty, czy inne urządzenie potrzebuje tej samej wymiany. Trwałym wynikiem jest konfiguracja, której operatora i cel potrafisz wyjaśnić.