DNSSEC versus VPN: co skutečně skryje vaše DNS dotazy?

Dva mechanismy dostávají stejný úkol a ani jeden ho neplní. DNSSEC odpovídá na otázku, zda data, která jste dostali, skutečně pocházejí ze zóny, která je publikuje, a VPN rozhoduje, kterou cestou vaše pakety půjdou. Ani jeden z nich ve všech případech neskryje jméno, na které jste se ptali, a nastavení, která vypadají, že by to měla dělat, se obvykle týkají transportu nebo směrování, nikoli validace. Když nejprve pojmenujete vrstvu, neurčitá otázka o soukromí se změní na konkrétní.

Tři tvrzení sloučená v jedno

Autenticita je tvrzení, že odpověď je ta, kterou zóna publikovala, a že nebyla cestou změněna. Důvěrnost je tvrzení, že nikdo na cestě nemůže přečíst dotaz ani odpověď. Směrování je tvrzení, že pakety jdou cestou, kterou jste zvolili, což je přesně to, co tunel poskytuje.

DNSSEC se zabývá prvním a o dalších dvou nic neříká. DoT a DoH se zabývají druhým pro úsek k resolveru. VPN se zabývá třetím a může ovlivnit i druhé, ale jen jako vedlejší efekt toho, kam provoz jde.

Provoz aplikací je čtvrtý případ: HTTPS chrání a ověřuje webovou výměnu mezi vaším klientem a stránkou a žádná DNS vrstva ho nenahradí.

Co validace podpisů umí a co ne

Validující resolver kontroluje řetěz podpisů od zóny až ke konfigurované kotvě důvěry a poté vrátí odpověď s nastaveným příznakem ověřených dat, pokud kontrola uspěje. Tento příznak je důkazem o datech, nikoli o spojení nebo o záměrech cíle.

Nemůže zabránit legitimnímu vlastníkovi zóny publikovat autentické záznamy pro službu, které byste neměli věřovat. Správně podepsaná odpověď z kompromitované domény je stále správně podepsaná a DNSSEC nemá názor na to, zda si ta doména vaše přihlašovací údaje zaslouží.

Také nic neskrývá. Dotaz i odpověď procházejí sítí ve formě, kterou může resolver a jakýkoli pozorovatel na této cestě přečíst, pokud transport nechrání jiná vrstva. Podepsaná odpověď a soukromá odpověď jsou různé vlastnosti a nasazení může mít jen jednu z nich. Otestujte obě, pokud vám záleží na kterékoli.

Odkud důvěrnost skutečně pochází

Šifrovaný transport k resolveru zabaluje DNS výměnu do TLS, takže resolver otázku stále vidí, ale cesta mezi vámi a jím ne. To přesouvá důvěru, místo aby ji odstranilo: více důvěřujete resolveru a méně místní síti.

VPN může nést dotazy k resolveru na druhé straně, což mění jak cestu, tak resolver, který je vidí. Je to rozhodnutí o směrování s dopadem na soukromí a ve spravované síti může být interní resolver jediný, kdo umí odpovědět na interní jména.

Kombinace, kterou lidé skutečně chtějí, jsou obvykle tři věci najednou: zapnutá validace, šifrovaný transport k resolveru, který si vybrali, a aplikační TLS na cíli. Každá je nezávislá a vynechání jedné nechá jinou mezeru.

Kontrolujte validaci a transport odděleně

Dva testy vyřeší většinu zmatku. První se ptá, zda resolver odpověď validoval; druhý, zda byl transport chráněn. Selhávají různými způsoby a ani jedno neimplikuje druhé.

Tyto příkazy vypíšou příznaky z validujícího dotazu, zopakují dotaz s vypnutou kontrolou a spustí místní validaci pomocí delv:

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

Odpověď s příznakem ověřených dat a přítomným podpisem ukazuje validaci na daném resolveru. Selhání validace pomocí delv ukazuje přerušený řetěz někde mezi zónou a kotvou důvěry, což je problém publikace, nikoli problém tunelu. Časový limit úplně bez příznaků je problém transportu nebo dosažitelnosti a zacházet s ním jako se selháním podpisu vás pošle na špatnou vrstvu.

Co dělat, když VPN rozbije vyhledávání

Pokud vyhledávání před tunelem fungovalo a po něm přestalo, porovnejte resolver, který používá každá cesta. Rozdělené tunelování, interní resolver dostupný jen tunelem a klient, který přepisuje nastavení resolveru, to všechno mění odpověď, aniž by se dotklo DNSSEC.

Globální vypnutí validace je špatný první krok, protože odstraňuje jediný mechanismus, který hlásí manipulaci, a neopraví resolver, který je nedostupný. Nejprve zúžte závadu: překlad, transport, validace, potom politika. Jen třetí patří DNSSEC a jen druhé šifrovanému transportu.