Šifruje váš VPN DNS, nebo jen další skok?

Zapnutí šifrovaného DNS na serveru VPN se často popisuje jako uzavření úniku a tento popis skrývá, které spojení se změnilo. Skok od klienta k resolveru a skok od resolveru k nadřazenému serveru jsou oddělená spojení s oddělenými vlastníky. Zašifrování jednoho nechá druhé přesně tak, jak bylo.

Než sáhnete na konfigurační soubor, zapište, kdo dotaz v každé fázi přijímá.

Dvě uspořádání vypadají na stránce nastavení stejně

V prvním uspořádání zařízení samo provozuje DNS over TLS a tunel toto spojení jen nese k resolveru, který jste zvolili. Relace TLS končí na resolveru, což znamená, že resolver dotaz vidí a výstup VPN vidí šifrovaný text, který přečíst nedokáže. Ve druhém uspořádání zařízení posílá běžný DNS tunelem k přeposílací komponentě na hostiteli VPN a ta otevírá vlastní šifrované spojení k nadřazenému resolveru. Obě v seznamu funkcí vypadají jako "šifrovaný DNS s VPN" a čitelný dotaz umísťují do různých budov.

Rozdíl je měřitelný, nikoli filozofický. Najděte relaci TLS na klientu, nebo na serveru, a zjistíte, které uspořádání skutečně máte.

Zmapujte řetězec resolverů, než ho změníte

Spočítejte resolvery na cestě a pojmenujte roli každého z nich. Přeposílací komponenta předává požadavek jinému resolveru, zatímco rekurzivní resolver dělá práci při hledání odpovědi a může mluvit přímo s autoritativními servery. Tyto role jsou definovány odděleně právě proto a definice resolveru v RFC 9076 stojí za přečtení, než budete předpokládat, že existuje jediné nadřazené cílové místo. Hostitel, který provozuje vlastní rekurzivní resolver, nemá jediné "nadřazené" místo k šifrování, což celý plán zneplatňuje.

Pak se zeptejte, kterou komponentu má klient nakonfigurovanou. Adresa DNS předaná profilem VPN říká, kam dotazy jdou, ne který proces je zodpovídá.

Všimněte si i chování při selhání. Pokud se šifrovaný nadřazený resolver stane nedostupným, selhává přeposílací komponenta zavřeně, vrací se k otevřenému textu, nebo přechází na jiný resolver? Toto rozhodnutí patří do záznamu, protože mění záruku soukromí v okamžiku, kdy je tunel nejméně zdravý.

Ověřte, který skok je šifrovaný

Začněte na klientu a ověřte, zda drží relaci TLS k portu 853. Dotaz, který se správně vyřeší přes port 53, o šifrování nic nedokazuje.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Potom přejděte na hostitele VPN a hledejte odchozí šifrované spojení, které přeposílací komponenta otevřela. Tabulka socketů říká, zda nadřazená relace TLS existuje a který proces ji vlastní:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Pokud klient ukazuje relaci TLS a server ne, jste v prvním uspořádání a server nemůže číst dotazy, které přeposílá na vrstvě IP. Pokud server ukazuje relaci TLS a klient běžný provoz na portu 53 uvnitř tunelu, jste ve druhém uspořádání: další skok je chráněn, ale přeposílací komponenta stále čte každé jméno, které si zařízení vyžádá. Tento druhý výsledek není selhání, ale nazývat ho end-to-end šifrováním je špatně.

Zapište vlastníka a chování při selhání

Vlastnictví určuje, co smíte slíbit. Vlastník zařízení ovládá šifrované spojení na straně klienta, zatímco správce VPN ovládá navazující spojení, které vytváří jeho přeposílací komponenta. Kdo neprovozuje ani jedno, může cestu jen popsat.

Než cokoli zapnete, zkontrolujte interní pojmenování. Posílat organizační jména veřejnému resolveru není rovnocenný návrh a zóna split-horizon, která existuje jen uvnitř sítě, se nadřazeně vůbec nepřeloží. Po změně otestujte jedno interní a jedno veřejné jméno a výsledek uchovejte spolu se změnou konfigurace. Pokud šifrovaná cesta rozbije překlad pro interní hostitele, opravou je pravidlo resolveru s omezeným rozsahem, ne širší tunel.

Skončete tím, že pro každý skok napíšete jednu větu: která komponenta dotaz přijala, zda byl tento skok šifrovaný a kdo může jméno přečíst. Když věta o hostiteli VPN stále říká, že dotazy čte, dokumentace by to měla uvádět, protože diagramu, který tvrdí opak, uvěří někdo, kdo ty příkazy nikdy nespustil.