El DNS xifrat sense VPN amaga la consulta, no la vostra adreça

Una prova de filtració de DNS que mostra la vostra xarxa domèstica no és evidència que el DNS xifrat hagi fallat, ni és evidència que res hagi funcionat. La prova respon una pregunta: a quin resolutor ha arribat aquesta consulta, des d’aquesta xarxa. Si això és un problema depèn del que protegíeu i de qui.

Escriviu l’objectiu abans d’executar qualsevol prova.

Pas 1: anomeneu la protecció que realment voleu

Tres objectius es barregen. Potser voleu que un observador al camí deixi de llegir consultes. Potser voleu que un resolutor concret deixi de rebre-les. Potser voleu que els llocs web que visiteu deixin de veure la vostra adreça domèstica. El DNS xifrat serveix el primer, canvia qui satisfà el segon i no fa absolutament res pel tercer.

Una VPN serveix el tercer i, segons el proveïdor, el primer. Cap de les dues eines no és un superconjunt de l’altra.

Pas 2: trieu un resolutor i verifiqueu-ne la identitat

DNS over TLS embolcalla la consulta en una sessió TLS amb el resolutor, i DNS over HTTPS l’embolcalla en una petició HTTP; RFC 7858 i RFC 8484 descriuen tots dos, i cap no necessita un túnel. El que importa operativament és que el certificat es verifiqui contra el nom que heu configurat, perquè una sessió xifrada amb la part equivocada és pitjor que text pla amb la correcta. Això vol dir mode estricte allà on la plataforma l’ofereix, no un mode oportunista que recula quan la verificació falla. Comproveu la sessió directament abans de confiar en el paràmetre: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

L’apretada de mans ha de nomenar el resolutor que heu configurat i retornar una cadena que pugueu verificar.

Pas 3: decidiu el comportament en cas de fallada

Cada implementació té una política per a un resolutor xifrat inabastable, i aquesta política és la decisió de privadesa. El mode estricte fa fallar la consulta, cosa que és visible i irritant. El mode oportunista reintenta en text pla, cosa que és invisible i estroba el propòsit justament el dia que importa. Trieu deliberadament i després anoteu la tria al costat del requisit.

A systemd-resolved això vol dir DNSOverTLS=yes en lloc de opportunistic; a Android vol dir el mode de nom d’amfitrió de Private DNS en lloc d’automàtic.

Comproveu què està realment en vigor amb resolvectl status | grep -i -A1 "dns over tls", perquè un fitxer drop-in que no s’ha recarregat mai no canvia res.

Pas 4: comproveu que les aplicacions segueixin el resolutor del sistema

Un navegador amb la seva pròpia configuració de DNS segur fa cas omís de la configuració del sistema, i també un runtime de contenidors amb un resolutor incrustat o un runtime de llenguatge que llegeix una llista fixada al codi. Feu que segueixin el sistema o configureu-los explícitament i anoteu-ho. Després mireu el comportament de reculada de cadascun, perquè no tots fallen tancats. L’inventari a la pràctica és curt: navegador, runtime de contenidors i qualsevol client VPN que també executeu.

Els noms privats de l’organització es queden al resolutor intern aprovat. Enviar-los a un servei públic perquè una prova quedi polida crea un problema diferent a propòsit.

Pas 5: llegiu la prova de filtració contra el requisit

Una prova que informa d’un resolutor inesperat és un senyal, no un veredicte. Pot ser que hagi observat el resolutor xifrat que preteníeu, un paràmetre específic d’una aplicació o una reculada a text pla que no sabíeu. Compareu el resolutor informat amb el que va configurar el pas 2 i compareu el resultat amb l’objectiu del pas 1.

Si l’objectiu era mantenir les consultes lluny de la xarxa local, una prova que mostra el vostre resolutor habitual és una troballa real. Si l’objectiu era l’anonimat mentre navegueu, cap paràmetre de DNS no ho hauria lliurat mai.

Escriviu la línia d’acceptació en la llengua de l’objectiu: aquestes consultes fan servir aquest resolutor verificat sota aquestes condicions. Qualsevol cosa més àmplia és una afirmació que no podeu provar.