DNSSEC of in VPN: hokker ferberget jo DNS-fragen?

Twa meganismen krije deselde taak tatocht en gjin fan beide docht it. DNSSEC antwurdet oft de gegevens dy’t jo krigen hawwe echt fan ’e sône komme dy’t se publisearret, en in VPN beslute hokker paad jo pakketten nimme. Gjin fan beide ferberget yn alle gefallen de namme dy’t jo fregen, en de ynstellings dy’t lykje dat se dat dwaan moatte geane meastentiids oer ferfier of rûtelearring en net oer falidaasje. As jo earst de laach beneame, wurdt in ûndúdlik fraach oer privacy in konkreet fraach.

Trije bewearings dy’t gearranne ta ien

Autentisiteit is de bewearing dat it antwurd dat is dat de sône publisearre hat en ûnderweis net feroare is. Fertroulikens is de bewearing dat nimmen op it paad de fraach of it antwurd lêze kin. Rûtelearring is de bewearing dat de pakketten in paad folgje dat jo keazen hawwe, en dat is krekt wat in tunnel biedt.

DNSSEC behannelet de earste en seit neat oer de oare twa. DoT en DoH behannelje de twadde foar de sprong nei de resolver. In VPN behannelet de tredde en kin ek de twadde beynfloedzje, mar allinnich as byeffekt fan wêr’t it ferkear hinne giet.

Tapassingsferkear is in fjirde gefal: HTTPS beskermet en autentisearret de webútwikseling tusken jo klant en de side, en gjin DNS-laach ferfangt it.

Wat hantekeningfalidaasje wol en net kin

In falidearjende resolver kontrolearret de keatling fan hantekeningen fan ’e sône oant in konfigurearre fertrouwensanker, en jout dan in antwurd werom mei de flagge foar autentisearre gegevens set as de kontrôle slagget. Dy flagge is bewiis oer de gegevens, net oer de ferbining of de bedoelingen fan ’e bestimming.

It kin in legitime sône-eigner net tsjinhâlde om autentike records te publisearjen foar in tsjinst dy’t jo net fertrouwe moatte. In korrekt ûndertekene antwurd fan in kompromittearre domein is noch altyd korrekt ûndertekene, en DNSSEC hat gjin miening oer de fraach oft dat domein jo oanmeldgegevens fertsjinnet.

It ferberget ek neat. De fraach en it antwurd geane troch it netwurk yn in foarm dy’t in resolver en elke waarnimmer op dat paad lêze kinne, útsein as in oare laach it ferfier beskermet. In ûndertekene antwurd en in privee antwurd binne ferskate eigenskippen, en in útrulling kin mar ien fan beide hawwe. Test beide as ien fan beide foar jo fan belang is.

Wêr’t fertroulikens echt wei komt

Fersifere resolverferfier pakt de DNS-útwikseling yn TLS, dus de resolver sjocht de fraach noch wol, mar it paad tusken jo en him net. Dat ferpleatst fertrouwen yn plak fan it fuort te heljen: jo fertrouwe de resolver mear en it lokale netwurk minder.

In VPN kin fragen nei in resolver oan ’e oare kant bringe, wat sawol it paad as de resolver dy’t se sjocht feroaret. Dat is in rûtelearringsbeslút mei in privacygefolch, en op in beheard netwurk kin de ynterne resolver de iennige wêze dy’t ynterne nammen beantwurdzje kin.

De kombinaasje dy’t minsken echt wolle is meastentiids trije dingen tagelyk: falidaasje oan, fersifere ferfier nei in resolver dy’t se sels keazen hawwe, en tapassings-TLS op ’e bestimming. Elk is ûnôfhinklik, en ien oerslaan lit in oare gat efter.

Kontrolearje falidaasje en ferfier apart

Twa tests lossen it measte fan ’e betizing op. De earste freget oft de resolver it antwurd falidearre hat; de twadde freget oft it ferfier beskerme wie. Se mislearje op ferskate manieren en gjin fan beide betsjuttet de oare.

Dizze opdrachten printsje de flaggen fan in falidearjende fraach, werhelje de fraach mei de kontrôle útskeakele en rinne lokale falidaasje mei delv:

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

In antwurd mei de flagge foar autentisearre gegevens en in oanwêzige hantekening lit falidaasje by dy resolver sjen. In falidaasjeflier mei delv lit in brutsen keatling earne tusken de sône en it fertrouwensanker sjen, wat in publikaasjeprobleem is en net in tunnelprobleem. In tiidferrin sûnder hokker flagge dan ek is in ferfier- of berikberensprobleem, en it behannelje as in hantekeningflier stjoert jo nei de ferkearde laach.

Wat te dwaan as in VPN opsykjen brekt

As opsykjen foar de tunnel wurke en dernei stopet, ferlykje de resolver dy’t elk paad brûkt. Splitst tunnelearjen, in ynterne resolver dy’t allinnich troch de tunnel berikber is, en in klant dy’t resolverynstellings oerskriuwt, feroarje allegear it antwurd sûnder DNSSEC oan te reitsjen.

Falidaasje wrâldwiid útskeakelje is de ferkearde earste stap, want it hellet it iennige meganisme fuort dat oer manipulaasje rapportearret en reparearret gjin resolver dy’t net berikber is. Behein earst de flater: resolúsje, ferfier, falidaasje en dan belied. Allinnich de tredde heart by DNSSEC, en allinnich de twadde heart by fersifere ferfier.