DNS oer TLS plus in VPN: hokker part is beskerme

DNS oer TLS fersiferet de útwikseling tusken in klant en de resolver dy't er keazen hat, en de resolver lêst noch altyd de namme. Dy sin hellet it measte fan de betizing oer DoT plus in VPN fuort. De tunnel beslút hokker paad de fersifere fraach nimt, wylst de resolver noch altyd heart wat frege is. Gjin fan beide meganismen ferfangt de oare, en gjin fan beide makket de oare oerstallich.

Fjouwer kontrôles beslute oft de regeling dy't jo hawwe dejinge is dêr't jo tinke dat jo hawwe.

Kontrôle 1: wat de fersifering dekt

DoT wikkelt de DNS-útwikseling yn TLS, dat in waarnimmer op it paad sjocht in ferbining nei in adres en poarte yn stee fan in namme yn in fraach. De resolver sels ûntsiferet en antwurdet. Fergelykje it mei DNS oer HTTPS: beide fersiferje, en se brûke ferskillende ferfierders, dat in netwurk dat webtrafyk tastiet, tastiet net automatysk in DoT-ferbining ta.

Dat ferskil is fan belang as in finzenisportaal of in filterjende middenboks 443 tastiet en 853 blokkearret. It ark dat dêr wurke, is gjin bewiis dat it oare dat sil.

Kontrôle 2: hokker rûte de fraach nimt

De rûte is in kwestje fan klantbelied. In DoT-resolver is te berikken troch de tunnel, bûten him, of fia in paad dat mei it netwurk feroaret. Hokker dat bart, hinget fan de rûtes ôf en fan oft de klant syn eigen DNS-socket beskermet. In tunnel dy't al it ferkear fangt, nimt de fraach meastentiids mei, wat it adres fan de resolver ek seit.

It sjen fan in resolveradres fan in tredde partij yn in test bewiist gjin omgong, en it sjen fan fersifering bewiist de bedoelde ûntfanger net. Lês de resolver en it paad apart, en beslút dan oft it pear is dat jo ûntwurpen hawwe.

Kontrôle 3: ynterne nammen

In organisaasje dy't ynterne nammen publisearret, hat in resolver nedich dy't dy records hâldt. In iepenbiere DoT-tsjinst ken jo privee nammeromte net, en it klanten dwaan nei ien garandearret dat dy nammen misse. Dat is de meast foarkommende praktyske eftergong as immen fersifere DNS oanset op in beheard apparaat.

Hâld de ynterne resolver foar ynterne efterheaksels en fersiferje dy sprong as belied dat easket, yn stee fan him te ferfangen troch in iepenbiere leveransier.

Kontrôle 4: gedrach by mislearring

In strang resolverynstelling sûnder berikbere resolver jouwt in mislearring fan nammesykjen wylst de tunnel oerein bliuwt. Sjoch nei de platfoarmmodus en syn dokumintearre weromfal yn stee fan kaaien of sertifikaten oan te reitsjen.

In weromfal dy't stil gewoane DNS brûkt, is in beliedsbeslút, net in gemak. Beslút oft mislearring sichtber wêze moat of nei eat swakkers ferfalle moat, en skriuw it antwurd op.

Fertrou it sertifikaat, net it antwurd

Brûk de hostnamme fan de leveransier en de ferifikaasjekonfiguraasje dy't foar de tsjinst dokumintearre is. TLS-kontrôles útskeakelje sadat in ûnbekende resolver antwurdet, jout jo in fersifere kanaal nei in net-ferifisearre einpunt, wat op ien bepaald punt minner is as de gewoane fraach dy't it ferfong: it liket feilich. De spesifikaasje fan DNS oer TLS set de ferwachtings fan autentikaasje efter dy kontrôle útinoar.

In antwurd fan in resolver dy't jo net autentisearje kinne, is in bewearing, gjin resultaat.

Wat dit ûnferklearre lit

DoT ferberget de namme net foar de resolver, ferberget it bestimmingsadres fan de ferbining net foar it netwurk, en beslút net oft de fraach troch de tunnel gongen is. Dat binne trije aparte fragen mei trije aparte antwurden.

Skriuw de identiteit fan de resolver, it transitpaad en it belied foar ynterne nammen as trije rigels op. De folgjende DNS-fraach dy't jo krije, sil ien fan har wêze.