DNSSEC vs VPN: kumb peidab sinu DNS-päringud?

Kaks mehhanismi saavad sama ülesande ja kumbki ei täida seda. DNSSEC vastab, kas saadud andmed pärinevad tõesti tsoonist, mis need avaldab, ja VPN otsustab, millist teed sinu paketid lähevad. Kumbki ei varja igal juhul nime, mille järele pärisid, ja seaded, mis näivad, nagu peaksid seda tegema, puudutavad tavaliselt transporti või marsruutimist, mitte valideerimist. Kihi esmalt nimetamine muudab ebamäärase privaatsusküsimuse konkreetseks.

Kolm väidet, mis sulanduvad üheks

Ehtsus on väide, et vastus on see, mille tsoon avaldas, ja et seda teel ei muudetud. Konfidentsiaalsus on väide, et keegi teel ei saa päringut ega vastust lugeda. Marsruutimine on väide, et paketid järgivad sinu valitud teed, ja täpselt seda pakub tunnel.

DNSSEC tegeleb esimesega ega ütle kahe ülejäänu kohta midagi. DoT ja DoH tegelevad teisega hüppe jaoks resolverini. VPN tegeleb kolmandaga ja võib mõjutada ka teist, kuid ainult selle kõrvalmõjuna, kuhu liiklus läheb.

Rakendusliiklus on neljas juhtum: HTTPS kaitseb ja autentib veebivahetust sinu kliendi ja saidi vahel ning ükski DNS-kiht ei asenda seda.

Mida allkirja valideerimine suudab ja ei suuda

Valideeriv resolver kontrollib allkirjade ahelat tsoonist konfigureeritud usaldusankruni ja tagastab seejärel vastuse, millel on autenditud andmete lipp seatud, kui kontroll õnnestub. See lipp on tõend andmete kohta, mitte ühenduse ega sihtkoha kavatsuste kohta.

See ei saa takistada seaduslikku tsooniomanikku avaldamast ehtsaid kirjeid teenuse kohta, mida sa ei peaks usaldama. Õigesti allkirjastatud vastus kompromiteeritud domeenist on endiselt õigesti allkirjastatud ja DNSSECil pole arvamust, kas see domeen väärib sinu mandaate.

See ei varja ka midagi. Päring ja vastus läbivad võrgu kujul, mida resolver ja iga vaatleja sellel teel saavad lugeda, kui mõni teine kiht transporti ei kaitse. Allkirjastatud vastus ja privaatne vastus on erinevad omadused ning juurutus võib olla ainult üks neist. Testi mõlemat, kui kumbki neist on sulle oluline.

Kust konfidentsiaalsus tegelikult tuleb

Krüpteeritud resolveri transport mässib DNS-vahetuse TLSi, nii et resolver näeb endiselt küsimust, aga tee sinu ja selle vahel mitte. See liigutab usaldust, mitte ei eemalda seda: usaldad resolverit rohkem ja kohalikku võrku vähem.

VPN võib kanda päringud teisel pool asuvale resolverile, mis muudab nii teed kui ka resolverit, kes neid näeb. See on marsruutimisotsus, millel on privaatsusjärg, ja hallatavas võrgus võib sisemine resolver olla ainus, kes suudab sisemistele nimedele vastata.

Kombinatsioon, mida inimesed tegelikult tahavad, on tavaliselt kolm asja korraga: valideerimine sees, krüpteeritud transport nende valitud resolverini ja rakenduse TLS sihtkohas. Igaüks on sõltumatu ja ühe vahelejätmine jätab teistsuguse lünga.

Kontrolli valideerimist ja transporti eraldi

Kaks testi lahendavad suurema osa segadusest. Esimene küsib, kas resolver valideeris vastuse; teine küsib, kas transport oli kaitstud. Need ebaõnnestuvad erineval viisil ja kumbki ei eelda teist.

Need käsud prindivad valideeriva päringu lipud, kordavad päringut kontrolli väljalülitamisega ja käivitavad kohaliku valideerimise käsuga delv:

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

Vastus, millel on autenditud andmete lipp ja olemasolev allkiri, näitab valideerimist selles resolveris. Valideerimise ebaõnnestumine käsuga delv näitab katkist ahelat kuskil tsooni ja usaldusankru vahel, mis on avaldamise probleem, mitte tunneli probleem. Aegumine ilma ühegi liputa on transporti või kättesaadavuse probleem ja selle käsitlemine allkirja veana saadab sind valesse kihti.

Mida teha, kui VPN rikub otsinguid

Kui otsingud töötasid enne tunnelit ja lakkavad pärast seda, võrdle resolverit, mida kumbki tee kasutab. Jagatud tunnelimine, ainult tunneli kaudu kättesaadav sisemine resolver ja klient, mis kirjutab resolveri seaded üle, muudavad kõik vastust ilma DNSSECit puudutamata.

Valideerimise globaalne väljalülitamine on vale esimene samm, sest see eemaldab ainus mehhanismi, mis teavitab rikkumisest, ega paranda resolverit, millele ei saa ligi. Kõigepealt kitsenda viga: lahendamine, transport, valideerimine ja seejärel poliitika. Ainult kolmas kuulub DNSSECi ja ainult teine kuulub krüpteeritud transpordi alla.