Geënkripteerde DNS sonder 'n VPN verberg die navraag, nie jou adres nie

’n DNS-lektoets wat jou tuisnetwerk wys, is nie bewys dat geënkripteerde DNS gefaal het nie, en dit is ook nie bewys dat iets gewerk het nie. Die toets beantwoord een vraag: watter oplosser het hierdie navraag van hierdie netwerk bereik. Of dit ’n probleem is, hang daarvan af wat jy wou beskerm en teen wie.

Skryf die doel neer voordat jy enige toets uitvoer.

Stap 1: noem die beskerming wat jy werklik wil hê

Drie doelwitte raak deurmekaar. Jy wil dalk hê dat ’n waarnemer op die pad moet ophou om navrae te lees. Jy wil dalk hê dat ’n bepaalde oplosser moet ophou om hulle te ontvang. Jy wil dalk hê dat die webwerwe wat jy besoek, moet ophou om jou tuisadres te sien. Geënkripteerde DNS dien die eerste, verander wie die tweede bevredig, en doen glad niks vir die derde nie.

’n VPN dien die derde en, afhangend van die verskaffer, die eerste. Nie een stuk gereedskap is ’n superset van die ander nie.

Stap 2: kies ’n oplosser en verifieer sy identiteit

DNS over TLS verpak die navraag in ’n TLS-sessie met die oplosser, en DNS over HTTPS verpak dit in ’n HTTP-versoek; RFC 7858 en RFC 8484 beskryf albei, en nie een het ’n tonnel nodig nie. Wat operasioneel saak maak, is dat die sertifikaat teen die naam wat jy opgestel het, geverifieer word, want ’n geënkripteerde sessie met die verkeerde party is erger as gewone teks aan die regte een. Dit beteken streng modus waar die platform dit bied, nie ’n opportunistiese modus wat terugval wanneer verifikasie misluk nie. Kontroleer die sessie direk voordat jy die instelling vertrou: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Die handdruk moet die oplosser noem wat jy opgestel het en ’n ketting terugstuur wat jy kan verifieer.

Stap 3: besluit oor die foutgedrag

Elke implementering het ’n beleid vir ’n onbereikbare geënkripteerde oplosser, en daardie beleid is die privaatheidbesluit. Streng modus laat die opsoek misluk, wat sigbaar en irriterend is. Opportunistiese modus probeer weer in gewone teks, wat onsigbaar is en die doel verydel op presies die dag wanneer dit saak maak. Kies doelbewus en teken dan die keuse langs die vereiste aan.

Op systemd-resolved beteken dit DNSOverTLS=yes eerder as opportunistic; op Android beteken dit die Private DNS-gasheernaam-modus eerder as outomaties.

Kontroleer wat werklik van krag is met resolvectl status | grep -i -A1 "dns over tls", want ’n drop-in-lêer wat nooit herlaai is nie, verander niks.

Stap 4: kontroleer dat toepassings die stelseloplosser volg

’n Blaaier met sy eie secure-DNS-instelling omseil die stelselkonfigurasie heeltemal, en so ook ’n houerruntime met ’n ingebedde oplosser of ’n taalruntime wat ’n hardgekodeerde lys lees. Maak daardie goed óf volg die stelsel óf stel hulle eksplisiet op en teken dit aan. Kyk dan na die terugvalgedrag van elkeen, want hulle faal nie almal gesluit nie. Die inventaris is in die praktyk kort: blaaier, houerruntime, en watter VPN-kliënt jy ook al hardloop.

Privaat organisasienaamruimtes bly op die goedgekeurde interne oplosser. Om hulle na ’n openbare diens te stuur sodat ’n toets netjies lyk, skep doelbewus ’n ander probleem.

Stap 5: lees die lektoets teen die vereiste

’n Toets wat ’n onverwagte oplosser rapporteer, is ’n aanduiding, nie ’n uitspraak nie. Dit het dalk jou beoogde geënkripteerde oplosser gesien, ’n toepassing-spesifieke instelling, of ’n gewone-teks-terugval waarvan jy nie geweet het nie. Vergelyk die gerapporteerde oplosser met wat stap 2 opgestel het, en vergelyk die resultaat met die doel van stap 1.

As die doel was om navrae van die plaaslike netwerk weg te hou, is ’n toets wat jou gewone oplosser wys ’n werklike bevinding. As die doel anonimiteit tydens blaai was, sou geen DNS-instelling dit ooit lewer nie.

Skryf die aanvaardingslyn in die taal van die doel: hierdie opsoeke gebruik hierdie geverifieerde oplosser onder hierdie voorwaardes. Enigiets breër is ’n bewering wat jy nie kan toets nie.