VPN-DNS tsjin DoH yn 'e browser: wat in lektest jo net fertelle kin

In lektestadres lit allinnich sjen hokker resolver antwurde. Fersifere fragen, splitst DNS en browserbelied bepale oft priveenammen noch oploss wurde.

De lektestside seit dat jo DNS goed is, de badge fan 'e browser seit feilich, en de ynterne wiki laadt noch hieltyd net. Alle trije kinne tagelyk wier wêze, want it adres fan in resolver is net itselde ding as it belied dat him keas of it paad dat de fraach naam. Wat minsken in DNS-lek neame is eins ien fraach: hokker resolver krige de namme, en wie dy kar opsetlik? Dat útsykje freget trije kontrôles, en allinnich de lêste betsjut it feroarjen fan in ynstelling.

Myt ien: de badge neamt jo resolver

In lektest lost in proefnamme op en rapportearret it adres dat antwurde. It rapportearret net it belied dat dy resolver keas, en as de fraach yn DNS oer HTTPS ferpakt is, kin in tuskenkast op it paad de namme hielendal net sjen. Twa hiel ferskillende masines meitsje deselde gerêststellende badge: ien wêr't de VPN 10.8.0.1 ynsleat en de browser dy brûkt, en ien wêr't de browser de systeemlist negearre en de namme troch de tunnel nei syn eigen fersifere provider stjoerde.

It ferskil is fan belang op it stuit dat in priveenamme mislearret. Yn 'e earste opset antwurdet de VPN-resolver foar de bedriuwsdomein; yn 'e twadde hat de browser him nea frege, sadat de koarte hostnamme net oplost en de flater der as in stikken VPN útsjocht. De kontrôle is gjin oare lektest, it is in syktocht nei in namme dy't mar ien resolver ken.

Myt twa: de browser ferlit de tunnel

DNS kiest in adres, routing draacht de ferbining, en dat binne twa aparte lagen. In fraach nei in iepenbiere DoH-provider is noch hieltyd TCP poarte 443 nei in routber adres. As jo routtabel de standertrûte nei de tunnel stjoert, giet dy fraach ek troch de tunnel. It merk fan 'e resolver beslút it paad net.

Wat browser-DoH feroaret is de ûntfanger fan 'e nammen. Dat is in echte privacybeslissing en in echte beliedsbeslissing, mar it is gjin routingomgong. As jo eask is dat nammen by de VPN-operator bliuwe, dan falt in fersifere fraach nei immen oars dy eask net, wylst it noch hieltyd de tunnel brûkt foar de werklike ferbining.

Myt trije: elke VPN oerwint elke browser

Feilich DNS yn in browser hat modi, net in skeakel: út, in standertprovider mei fangnet, in eigen sjabloan, of in belied dat troch it bestjoeringssysteem of de organisaasje oplein wurdt. Krekt it fangnet gefal produsearret de ûnregelmjittige rapporten. As it fersifere einpunt net berikber is, kin de browser weromfalle op de systeemresolver, sadat deselde laptop moandei in priveenamme goed oplost en tiisdei net.

Tagelyk sette de measte VPN-klanten de systeemresolver as de ferbining omheech giet en sette de foarige werom as dy delgiet. In browser mei in eigen fersifere resolver merkt dy weromsetting hielendal net. Dêrom hâldt itselde profyl him op twa laptops oars en dêrom liket resolv.conf goed wylst de browser noch altyd immen oars freget.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Fier dy út wylst jo ferbûn binne, notearje hokker domeinen elke resolver opeasket, en fergelykje dat mei wat de browser oer syn eigen modus rapportearret. Mozilla's DoH-dokumintaasje is in ridlike beskriuwing fan hoe't it standert- en fangnetgedrach fan in browser wurkje moat.

De beslissing hat trije ynfierten, net ien

Priveenammen, betrouwen yn 'e operator en berikberens beslisse de goede oardering. Nammen dy't allinnich de VPN-resolver ken twinge splitst DNS ôf: it privee efterheaksel giet nei de ynsleine resolver, al it oare folget it belied dat jo foar iepenbiere nammen keazen hawwe. Betrouwen yn 'e operator beslút oft iepenbiere nammen ek nei dy resolver of nei in aparte tsjinst moatte. Berikberens beslút oft jo keazen fersifere resolver op dit netwurk hielendal brûkber is.

ConditionWhat it forces
Internal names must resolveSplit DNS: private suffixes to the VPN resolver, the rest to your chosen default
Queries must stay with one operatorPin both the system resolver and the browser mode, and disable fallback
Resolver only reachable through the tunnelKeep the pushed resolver; do not point DoH at an endpoint your routes exclude

Gjin fan dizze rigen is in universele oanbefelling. In resolver dy't troch de VPN betsjinne wurdt, konsintrearret waarnimmingen by dy operator; in aparte tsjinst foeget noch in ûntfanger fan 'e frege nammen ta. Gjin fan beide oarderings bewiist eat oer bewarjen, útsein as jo it belied lêze.

Skriuw de beslissing per profyl op, want dizze ynstellingen driuwe. In profyl dat ferline moanne in resolver ynsleat, sleeit hjoed miskien neat yn, en de browser hâldt mei nocht in âld eigen einpunt dat noch antwurdet. Wat yn 'e notysje heart, is it adres fan 'e resolver, de efterheaksels dy't it besit en de modus fan 'e browser, net it merk fan 'e tsjinst.

Test it belied dat jo tinke dat jo konfigurearre hawwe

Test op namme, net op badge. Los in iepenbiere namme en in priveenamme op fia de systeemresolver, en werhelje dat dan yn 'e browser mei syn eigen feilige DNS-ynstelling yn 'e modus dy't jo fan plan binne te brûken. As de priveenamme allinnich yn 'e browser mislearret, hawwe jo de ûntfanger-misferhâlding fûn sûnder ien VPN-ynstelling oan te reitsjen.

Ferbyn dan opnij en kontrolearje it weromsetten, want dêr wenje de oerdrachsflaters: ferbrek, befêstigje dat de foarige resolver weromkaam, ferbyn opnij, befêstigje dat de ynsleine weromkaam. Test as lêste in browser mei in beheard belied as jo dy hawwe, want dy modus kin jo feroaring hielendal wegerje en stil de foarige resolver hâlde.

Begjin mei de fraach oer de nammromte en jo foarkomme it measte hjirfan. As de masine ynterne nammen berikke moat, is de fersifere resolver fan 'e browser in beslissing oer allinnich de iepenbiere helte, en de privee helte bliuwt by wat de VPN ek ynsleat.

Relatearre artikelen