DNSSEC vagy VPN: melyik rejti el a DNS-lekérdezéseidet?

Két mechanizmus kapja ugyanazt a feladatot, és egyik sem végzi el. A DNSSEC arra válaszol, hogy a kapott adatok valóban attól a zónától származnak-e, amely közzéteszi őket, a VPN pedig eldönti, melyik útvonalon haladnak a csomagjai. Egyik sem rejti el minden esetben a kért nevet, és a beállítások, amelyekről úgy tűnik, hogy ezt kellene tenniük, általában a szállításról vagy az útvonalválasztásról szólnak, nem a validálásról. Ha először megnevezi a réteget, a homályos adatvédelmi kérdés konkrét kérdéssé válik.

Három állítás, amely eggyé olvad

A hitelesség az az állítás, hogy a válasz az, amelyet a zóna közzétett, és az úton nem módosult. A bizalmasság az az állítás, hogy az útvonalon senki nem tudja elolvasni a lekérdezést vagy a választ. Az útvonalválasztás az az állítás, hogy a csomagok az Ön által választott útvonalon haladnak, és pontosan ezt nyújtja egy alagút.

A DNSSEC az elsővel foglalkozik, a másik kettőről nem mond semmit. A DoT és a DoH a másodikkal foglalkozik a feloldóig tartó ugrásnál. A VPN a harmadikkal foglalkozik, és a másodikra is hathat, de csak annak mellékhatásaként, hogy hová megy a forgalom.

Az alkalmazásforgalom negyedik eset: a HTTPS védi és hitelesíti a webes cserét az ügyfél és a webhely között, és egyetlen DNS-réteg sem helyettesíti.

Mit tud és mit nem tud az aláírás-validálás

A validáló feloldó ellenőrzi az aláírások láncát a zónától egy beállított bizalmi horgonyig, majd sikeres ellenőrzés esetén visszaadja a választ a hitelesített adatok jelzőjével bekapcsolva. Ez a jelző az adatokról szóló bizonyíték, nem a kapcsolatról vagy a cél szándékairól.

Nem akadályozhatja meg egy jogszerű zónatulajdonost abban, hogy hiteles rekordokat tegyen közzé egy olyan szolgáltatásról, amelyben nem lenne szabad megbíznia. Egy kompromittált domainről érkező helyesen aláírt válasz továbbra is helyesen aláírt, és a DNSSEC-nek nincs véleménye arról, hogy az a domain érdemli-e a hitelesítő adatait.

Semmit sem rejt el. A lekérdezés és a válasz olyan formában halad át a hálózaton, amelyet a feloldó és az útvonal bármely megfigyelője el tud olvasni, kivéve ha egy másik réteg védi a szállítást. Az aláírt válasz és a privát válasz különböző tulajdonságok, és egy telepítés csak az egyikkel rendelkezhet. Tesztelje mindkettőt, ha bármelyik fontos Önnek.

Honnan származik valójában a bizalmasság

A titkosított feloldó-szállítás TLS-be csomagolja a DNS-cserét, így a feloldó továbbra is látja a kérdést, de az Ön és közte lévő útvonal nem. Ez elmozdítja a bizalmat ahelyett, hogy megszüntetné: jobban bízik a feloldóban és kevésbé a helyi hálózatban.

A VPN lekérdezéseket vihet a túloldali feloldóhoz, ami megváltoztatja mind az útvonalat, mind azt a feloldót, amely látja őket. Ez útvonalválasztási döntés adatvédelmi következménnyel, és egy kezelt hálózaton a belső feloldó lehet az egyetlen, amely képes válaszolni a belső nevekre.

A kombináció, amit az emberek valójában szeretnének, általában három dolog egyszerre: bekapcsolt validálás, titkosított szállítás az általuk választott feloldóhoz és alkalmazás-TLS a célon. Mindegyik független, és egy kihagyása más rést hagy.

Ellenőrizze külön a validálást és a szállítást

Két teszt tisztázza a zavar nagy részét. Az első azt kérdezi, validálta-e a feloldó a választ; a második azt, hogy védett volt-e a szállítás. Különböző módokon hibáznak, és egyik sem jelenti a másikat.

Ezek a parancsok kiírják egy validáló lekérdezés jelzőit, megismétlik a lekérdezést kikapcsolt ellenőrzéssel, és helyi validálást futtatnak a delv segítségével:

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

A hitelesített adatok jelzőjével és meglévő aláírással rendelkező válasz validálást mutat azon a feloldón. A validálás hibája a delv használatával megszakadt láncot mutat valahol a zóna és a bizalmi horgony között, ami közzétételi probléma, nem alagútprobléma. A jelzők nélküli időtúllépés szállítási vagy elérhetőségi probléma, és aláírási hibaként kezelni a rossz réteghez küldi.

Mit tegyen, ha a VPN elrontja a kereséseket

Ha a keresések az alagút előtt működtek és utána leállnak, hasonlítsa össze, melyik feloldót használja az egyes útvonalak. A megosztott alagutazás, a csak az alagúton át elérhető belső feloldó és a feloldó beállításait átíró ügyfél mind megváltoztatja a választ anélkül, hogy hozzányúlna a DNSSEC-hez.

A validálás globális kikapcsolása rossz első lépés, mert eltávolítja az egyetlen mechanizmust, amely jelentést ad a manipulációról, és nem javítja meg az elérhetetlen feloldót. Először szűkítse a hibát: feloldás, szállítás, validálás, majd irányelv. Csak a harmadik tartozik a DNSSEC-hez, és csak a második a titkosított szállításhoz.