DNSSEC teenoor ’n VPN: watter een verberg jou DNS-navrae?

Twee meganismes kry dieselfde taak toegeskryf en nie een van hulle voer dit uit nie. DNSSEC beantwoord of die data wat jy ontvang het werklik van die sone kom wat dit publiseer, en ’n VPN besluit watter pad jou pakkette volg. Nie een van hulle verberg in elke geval die naam wat jy gevra het nie, en die instellings wat lyk of hulle dit moet doen, gaan gewoonlik oor vervoer of roetering eerder as oor validering. Om eers die laag te benoem, verander ’n vae privaatheidsvraag in ’n spesifieke een.

Drie aansprake wat tot een saamgevoeg word

Egtheid is die aanspraak dat die antwoord die een is wat die sone gepubliseer het en nie onderweg verander is nie. Vertroulikheid is die aanspraak dat niemand op die pad die navraag of die antwoord kan lees nie. Roetering is die aanspraak dat die pakkette ’n pad volg wat jy gekies het, wat juis is wat ’n tonnel bied.

DNSSEC spreek die eerste aan en sê niks oor die ander twee nie. DoT en DoH spreek die tweede aan vir die hop na die resolver. ’n VPN spreek die derde aan en kan ook die tweede beïnvloed, maar net as ’n newe-effek van waar die verkeer heen gaan.

Toepassingsverkeer is ’n vierde geval: HTTPS beskerm en verifieer die webuitruiling tussen jou kliënt en die webwerf, en geen DNS-laag vervang dit nie.

Wat handtekeningvalidering kan en nie kan doen nie

’n Validerende resolver kontroleer die ketting van handtekeninge van die sone op na ’n gekonfigureerde vertrouensanker, en gee dan ’n antwoord terug met die egtheid-data-vlag gestel wanneer die kontrole slaag. Daardie vlag is bewys oor die data, nie oor die verbinding of die bestemming se bedoelings nie.

Dit kan nie ’n wettige sone-eienaar stop om egte rekords te publiseer vir ’n diens wat jy nie moet vertrou nie. ’n Korrek ondertekende antwoord van ’n gekompromitteerde domein is steeds korrek onderteken, en DNSSEC het geen mening oor of daardie domein jou aanmeldingsgegewens verdien nie.

Dit verberg ook niks nie. Die navraag en die antwoord kruis die netwerk in ’n vorm wat ’n resolver en enige waarnemer op daardie pad kan lees, tensy ’n ander laag die vervoer beskerm. ’n Ondertekende antwoord en ’n private antwoord is verskillende eienskappe, en ’n ontplooiing kan enigeen alleen hê. Toets albei as enigeen vir jou saak maak.

Waar vertroulikheid werklik vandaan kom

Geënkripteerde resolver-vervoer verpak die DNS-uitruiling in TLS, so die resolver sien steeds die vraag, maar die pad tussen jou en dit nie. Dit verskuif vertroue eerder as om dit te verwyder: jy vertrou die resolver meer en die plaaslike netwerk minder.

’n VPN kan navrae na ’n resolver aan die ander kant dra, wat beide die pad en die resolver wat hulle sien, verander. Dit is ’n roeteringsbesluit met ’n privaatheidsgevolg, en op ’n bestuurde netwerk is die interne resolver dikwels die enigste een wat interne name kan beantwoord.

Die kombinasie wat mense werklik wil hê, is gewoonlik drie dinge gelyktydig: validering aan, geënkripteerde vervoer na ’n resolver wat hulle gekies het, en toepassings-TLS op die bestemming. Elkeen is onafhanklik, en om een oor te slaan laat ’n ander gaping.

Kontroleer validering en vervoer afsonderlik

Twee toetse beslis die meeste verwarring. Die eerste vra of die resolver die antwoord gevalideer het; die tweede vra of die vervoer beskerm is. Hulle misluk op verskillende maniere en nie een impliseer die ander nie.

Hierdie opdragte druk die vlae van ’n validerende navraag, herhaal die navraag met kontrole gedeaktiveer, en voer plaaslike validering uit met delv:

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

’n Antwoord met die egtheid-data-vlag en ’n handtekening teenwoordig wys validering by daardie resolver. ’n Valideringsfout met delv wys ’n gebreekte ketting ergens tussen die sone en die vertrouensanker, wat ’n publikasieprobleem eerder as ’n tonnelprobleem is. ’n Tydverstrekking met geen vlae hoegenaamd nie is ’n vervoer- of bereikbaarheidsprobleem, en om dit as ’n handtekeningfout te behandel, stuur jou na die verkeerde laag.

Wat om te doen wanneer ’n VPN opsoek breek

As opsoek voor die tonnel gewerk het en daarna stop, vergelyk die resolver wat elke pad gebruik. Gesplete tonnelering, ’n interne resolver wat net deur die tonnel bereikbaar is, en ’n kliënt wat resolver-instellings herskryf, verander almal die antwoord sonder om DNSSEC aan te raak.

Om validering globaal te deaktiveer is die verkeerde eerste stap, want dit verwyder die enigste meganisme wat manipulasie rapporteer en maak nie ’n resolver reg wat nie bereik kan word nie. Vernou eers die fout: resolusie, vervoer, validering, dan beleid. Net die derde behoort aan DNSSEC, en net die tweede behoort aan geënkripteerde vervoer.