DNS przez TLS plus VPN: która część jest chroniona

DNS przez TLS szyfruje wymianę między klientem a resolverem, który wybrał, a resolver nadal czyta nazwę. To zdanie rozstrzyga większość zamieszania wokół DoT i VPN. Tunel decyduje, którą drogą pójdzie zaszyfrowane zapytanie, a resolver wciąż dowiaduje się, o co pytano. Żaden mechanizm nie zastępuje drugiego i żaden nie czyni drugiego zbędnym.

Cztery kontrole rozstrzygają, czy układ, który masz, jest tym, który myślisz, że masz.

Kontrola 1: co obejmuje szyfrowanie

DoT opakowuje wymianę DNS w TLS, więc obserwator na drodze widzi połączenie z adresem i portem, a nie nazwę w zapytaniu. Sam resolver odszyfrowuje i odpowiada. Porównaj to z DNS przez HTTPS: oba szyfrują i używają różnych transportów, więc sieć, która pozwala na ruch webowy, nie pozwala automatycznie na połączenie DoT.

Ta różnica ma znaczenie, gdy portal przechwytujący albo filtrująca skrzynka pośrednicząca pozwala na 443 i blokuje 853. Narzędzie, które tam działało, nie jest dowodem, że zadziała drugie.

Kontrola 2: którą trasą idzie zapytanie

Trasa to kwestia polityki klienta. Do resolvera DoT można dotrzeć przez tunel, spoza niego albo drogą, która zmienia się wraz z siecią. Który przypadek wystąpi, zależy od tras i od tego, czy klient chroni własne gniazdo DNS. Tunel, który przechwytuje cały ruch, zwykle zabiera zapytanie ze sobą, cokolwiek mówi adres resolvera.

Zobaczenie w teście adresu resolvera strony trzeciej nie dowodzi obejścia, a zobaczenie szyfrowania nie dowodzi zamierzonego odbiorcy. Czytaj resolver i trasę osobno, a potem zdecyduj, czy para jest tą, którą zaprojektowałeś.

Kontrola 3: nazwy wewnętrzne

Organizacja, która publikuje nazwy wewnętrzne, potrzebuje resolvera trzymającego te rekordy. Publiczna usługa DoT nie zna twojej prywatnej przestrzeni nazw, a skierowanie klienta do niej gwarantuje, że te nazwy zawiodą. To najczęstsza praktyczna regresja, gdy ktoś włącza szyfrowany DNS na zarządzanym urządzeniu.

Zachowaj wewnętrzny resolver dla sufiksów wewnętrznych i szyfruj ten przeskok, jeśli polityka tego wymaga, zamiast zastępować go publicznym dostawcą.

Kontrola 4: zachowanie przy awarii

Ścisłe ustawienie resolvera bez osiągalnego resolvera powoduje błąd rozwiązywania nazw, podczas gdy tunel pozostaje podniesiony. Patrz na tryb platformy i jego udokumentowany tryb rezerwowy, zamiast dotykać kluczy lub certyfikatów.

Tryb rezerwowy, który po cichu używa zwykłego DNS, jest decyzją polityki, a nie wygodą. Zdecyduj, czy awaria ma być widoczna, czy ma degradować do czegoś słabszego, i zapisz odpowiedź.

Ufaj certyfikatowi, nie odpowiedzi

Użyj nazwy hosta dostawcy i konfiguracji weryfikacji udokumentowanych dla usługi. Wyłączenie kontroli TLS, aby odpowiedział nieznany resolver, daje zaszyfrowany kanał do niezweryfikowanego punktu końcowego, co jest gorsze od zastąpionego zwykłego zapytania w jednym konkretnym aspekcie: wygląda bezpiecznie. Specyfikacja DNS przez TLS przedstawia oczekiwanie uwierzytelnienia stojące za tą kontrolą.

Odpowiedź od resolvera, którego nie możesz uwierzytelnić, jest twierdzeniem, a nie wynikiem.

Co to pozostawia niewyjaśnione

DoT nie ukrywa nazwy przed resolverem, nie ukrywa adresu docelowego połączenia przed siecią i nie decyduje, czy zapytanie szło przez tunel. To trzy osobne pytania z trzema osobnymi odpowiedziami.

Zapisz tożsamość resolvera, trasę tranzytu i politykę nazw wewnętrznych jako trzy linie. Następne pytanie o DNS, jakie dostaniesz, będzie jednym z nich.