Ĉifrita DNS sen VPN kaŝas la konsulton, ne vian adreson

Lika testo de DNS, kiu montras vian hejman reton, ne estas pruvo, ke ĉifrita DNS malsukcesis, kaj ankaŭ ne pruvo, ke io ajn funkciis. La testo respondas unu demandon: kiun risolvilon atingis ĉi tiu konsulto el ĉi tiu reto. Ĉu tio estas problemo dependas de tio, kion vi protektis kaj kontraŭ kiu.

Skribu la celon antaŭ ol lanĉi ajnan teston.

Paŝo 1: nomu la protekton, kiun vi vere volas

Tri celoj miksiĝas. Vi eble volas, ke observanto sur la vojo ĉesu legi konsultojn. Vi eble volas, ke aparta risolvilo ĉesu ricevi ilin. Vi eble volas, ke la retejoj, kiujn vi vizitas, ĉesu vidi vian hejman adreson. Ĉifrita DNS utilas al la unua, ŝanĝas kiu plenumas la duan, kaj faras absolute nenion por la tria.

VPN utilas al la tria kaj, laŭ la provizanto, al la unua. Neniu el la du iloj estas superaro de la alia.

Paŝo 2: elektu risolvilon kaj kontrolu ĝian identecon

DNS over TLS envovlas la konsulton en TLS-sesion kun la risolvilo, kaj DNS over HTTPS envovlas ĝin en HTTP-peton; RFC 7858 kaj RFC 8484 priskribas ambaŭ, kaj neniu bezonas tunelon. Operacie gravas, ke la atestilo estas kontrolata kontraŭ la nomo, kiun vi agordis, ĉar ĉifrita sesio kun la malĝusta partio estas pli malbona ol klara teksto kun la ĝusta. Tio signifas striktan reĝimon tie, kie la platformo ofertas ĝin, ne oportunisman reĝimon, kiu retiriĝas kiam la kontrolo malsukcesas. Kontrolu la sesion rekte antaŭ ol fidi la agordon: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

La manpremo devus nomi la risolvilon, kiun vi agordis, kaj redoni ĉenon, kiun vi povas kontroli.

Paŝo 3: decidi la konduton ĉe malsukceso

Ĉiu efektivigo havas politikon por neatingebla ĉifrita risolvilo, kaj tiu politiko estas la privateca decido. Strikta reĝimo malsukcesigas la serĉon, kio estas videbla kaj ĝena. Oportunisma reĝimo reprovas per klara teksto, kio estas nevidebla kaj neniigas la celon ĝuste en la tago, kiam ĝi gravas. Elektu konscie, poste notu la elekton apud la postulo.

Ĉe systemd-resolved tio signifas DNSOverTLS=yes anstataŭ opportunistic; ĉe Android ĝi signifas la reĝimon de gastigantnomo Private DNS anstataŭ aŭtomata.

Kontrolu, kio efektive validas, per resolvectl status | grep -i -A1 "dns over tls", ĉar drop-in-dosiero, kiu neniam estis reŝargita, ŝanĝas nenion.

Paŝo 4: kontrolu, ĉu aplikaĵoj sekvas la sisteman risolvilon

Retumilo kun propra agordo pri sekura DNS tute preterpasas la sisteman agordon, kaj same ujo-rultempo kun enkonstruita risolvilo aŭ lingva rultempo, kiu legas malmolan liston. Aŭ igi ilin sekvi la sistemon, aŭ agordi ilin eksplicite kaj noti tion. Poste rigardu la retiriĝan konduton de ĉiu, ĉar ne ĉiuj malsukcesas fermite. La inventaro estas mallonga en praktiko: retumilo, ujo-rultempo, kaj ajna VPN-kliento, kiun vi ankaŭ rulas.

Privataj organizaj nomoj restas ĉe la aprobita interna risolvilo. Sendi ilin al publika servo, por ke testo aspektu ordema, intence kreas alian problemon.

Paŝo 5: legu la likan teston kontraŭ la postulo

Testo, kiu raportas neatenditan risolvilon, estas indiko, ne verdikto. Eble ĝi observis vian celitan ĉifritan risolvilon, agordon specifan al aplikaĵo, aŭ retiriĝon al klara teksto, pri kiu vi ne sciis. Komparu la raportitan risolvilon kun tio, kion agordis paŝo 2, kaj komparu la rezulton kun la celo el paŝo 1.

Se la celo estis teni konsultojn for de la loka reto, testo montranta vian ordinaran risolvilon estas reala trovaĵo. Se la celo estis anonimeco dum retumado, neniu DNS-agordo iam liverus ĝin.

Skribu la akceptan linion en la lingvo de la celo: ĉi tiuj serĉoj uzas ĉi tiun kontrolitan risolvilon sub ĉi tiuj kondiĉoj. Io ajn pli vasta estas aserto, kiun vi ne povas testi.