Fersifere DNS sûnder VPN ferberget de query, net jo adres

In DNS-lekktest dy't jo thúsnetwurk sjen lit, is gjin bewiis dat fersifere DNS mislearre is, en it is ek gjin bewiis dat eat wurke hat. De test beantwurdet ien fraach: hokker resolver hat dizze query fan dit netwurk berikt. Oft dat in probleem is, hinget ôf fan wat jo beskermen en tsjin wa.

Skriuw it doel op foardat jo in test útfiere.

Stap 1: neam de beskerming dy't jo echt wolle

Trije doelen reitsje trochinoar. Jo wolle miskien dat in waarnimmer op it paad ophâldt mei it lêzen fan queries. Jo wolle miskien dat in beskaat resolver ophâldt se te ûntfangen. Jo wolle miskien dat de websites dy't jo besykje ophâlde jo thúsadres te sjen. Fersifere DNS tsjinnet it earste, feroaret wa't it twadde ferfollet, en docht foar it tredde hielendal neat.

In VPN tsjinnet it tredde en, ôfhinklik fan 'e provider, it earste. Gjin fan beide ark is in boppeset fan it oare.

Stap 2: kies in resolver en ferifiearje syn identiteit

DNS over TLS pakt de query yn in TLS-sesje mei de resolver, en DNS over HTTPS pakt him yn in HTTP-fersyk; RFC 7858 en RFC 8484 beskriuwe beide, en gjin fan beide hat in tunnel nedich. Wat operasjoneel wichtich is, is dat it sertifikaat ferifiearre wurdt tsjin de namme dy't jo konfigurearre hawwe, want in fersifere sesje mei de ferkearde partij is slimmer as platte tekst mei de goede. Dat betsjut strikte modus wêr't it platfoarm it biedt, net in opportunistyske modus dy't weromgiet as de ferifikaasje mislearret. Kontrolearje de sesje direkt foardat jo de ynstelling fertrouwe: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

De handshake moat de resolver neame dy't jo konfigurearre hawwe en in keatling weromjaan dy't jo ferifiearje kinne.

Stap 3: beslute it gedrach by mislearring

Elke ymplemintaasje hat in belied foar in ûnberikbere fersifere resolver, en dat belied is de privacybeslissing. Strikte modus lit it sykjen mislearje, wat sichtber en yrritant is. Opportunistyske modus besiket it opnij yn platte tekst, wat ûnsichtber is en it doel krekt deis dat it telt ûndergrêft. Kies bewust en skriuw de kar dan njonken de eask.

Op systemd-resolved betsjut dat DNSOverTLS=yes ynstee fan opportunistic; op Android betsjut it de hostnamemodus fan Private DNS ynstee fan automatysk.

Kontrolearje wat eins fan krêft is mei resolvectl status | grep -i -A1 "dns over tls", want in drop-in-bestân dat nea opnij laden is, feroaret neat.

Stap 4: kontrolearje oft applikaasjes de resolver fan it systeem folgje

In browser mei syn eigen ynstelling foar feilige DNS giet folslein om 'e systeemkonfiguraasje hinne, en sa docht in container-runtime mei in ynboude resolver ek, of in taal-runtime dy't in hurdcodearre list lêst. Lit se it systeem folgje of konfigurearje se eksplisyt en skriuw dat op. Sjoch dan nei it weromfalgedrach fan elk, want se mislearje net allegear sletten. De ynventaris is yn 'e praktyk koart: browser, container-runtime en hokker VPN-klant jo ek draaie.

Private nammen fan 'e organisaasje bliuwe by de goedkarde ynterne resolver. Se nei in publike tsjinst stjoere sadat in test der skjin útsjocht, makket mei opsetsin in oar probleem.

Stap 5: lês de lekktest tsjin de eask

In test dy't in ûnferwachte resolver rapportearret is in oanwizing, gjin útspraak. Hy hat miskien jo bedoelde fersifere resolver sjoen, in ynstelling spesifyk foar in applikaasje, of in weromfal nei platte tekst dêr't jo net fan wisten. Fergelykje de rapportearre resolver mei wat stap 2 konfigurearre, en fergelykje it resultaat mei it doel fan stap 1.

As it doel wie om queries fuort fan it lokale netwurk te hâlden, is in test dy't jo gewoane resolver sjen lit in echte befinning. As it doel anonymiteit by it browsen wie, soe gjin DNS-ynstelling dat ea levere hawwe.

Skriuw de akseptaasjeline yn 'e taal fan it doel: dizze sykjen brûke dizze ferifiearre resolver ûnder dizze betingsten. Alles breder is in bewearing dy't jo net testen kinne.