O DNS cifrado sen VPN oculta a consulta, non o teu enderezo

Unha proba de fuga de DNS que mostra a túa rede doméstica non é proba de que o DNS cifrado fallase, nin é proba de que algo funcionase. A proba responde unha pregunta: a que resolvedor chegou esta consulta desde esta rede. Se iso é un problema depende do que protexías e de quen.

Escribe o obxectivo antes de executar calquera proba.

Paso 1: nomea a protección que realmente queres

Tres obxectivos mestúranse. Pode que queiras que un observador na ruta deixe de ler consultas. Pode que queiras que un resolvedor concreto deixe de recibilas. Pode que queiras que os sitios web que visitas deixen de ver o teu enderezo de casa. O DNS cifrado serve o primeiro, cambia quen satisfai o segundo e non fai absolutamente nada polo terceiro.

Unha VPN serve o terceiro e, segundo o provedor, o primeiro. Ningunha das dúas ferramentas é un superconxunto da outra.

Paso 2: escolle un resolvedor e verifica a súa identidade

DNS over TLS envolve a consulta nunha sesión TLS co resolvedor, e DNS over HTTPS envólvea nunha solicitude HTTP; RFC 7858 e RFC 8484 describen ambas, e ningunha necesita un túnel. O importante na práctica é que o certificado se verifique contra o nome que configurases, porque unha sesión cifrada coa parte equivocada é peor que texto simple coa correcta. Iso significa modo estrito onde a plataforma o ofrece, non un modo oportunista que retrocede cando a verificación falla. Comproba a sesión directamente antes de confiar no axuste: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

A aperta de mans debería nomear o resolvedor que configurases e devolver unha cadea que poidas verificar.

Paso 3: decide o comportamento ante fallos

Cada implementación ten unha política para un resolvedor cifrado inalcanzable, e esa política é a decisión de privacidade. O modo estrito fai fallar a busca, o cal é visible e irritante. O modo oportunista reintenta en texto simple, o cal é invisible e arruína o propósito xusto o día en que importa. Escolle a conciencia e despois anota a elección xunto ao requisito.

En systemd-resolved iso significa DNSOverTLS=yes en lugar de opportunistic; en Android significa o modo de nome de host de Private DNS en lugar de automático.

Comproba que está realmente en vigor con resolvectl status | grep -i -A1 "dns over tls", porque un ficheiro drop-in que nunca se recargou non cambia nada.

Paso 4: comproba que as aplicacións seguen o resolvedor do sistema

Un navegador co seu propio axuste de DNS seguro ignora por completo a configuración do sistema, e tamén un runtime de contedores cun resolvedor integrado ou un runtime de linguaxe que le unha lista fixada no código. Ou fas que sigan o sistema ou os configuras explicitamente e anótalo. Despois mira o comportamento de retroceso de cada un, porque non todos fallan pechados. O inventario na práctica é curto: navegador, runtime de contedores e calquera cliente VPN que tamén executes.

Os nomes privados da organización quedan no resolvedor interno aprobado. Envialos a un servizo público para que unha proba quede ordenada crea a propósito un problema distinto.

Paso 5: le a proba de fuga contra o requisito

Unha proba que informa dun resolvedor inesperado é unha pista, non un veredicto. Pode que observase o resolvedor cifrado que pretendías, un axuste específico dunha aplicación ou un retroceso a texto simple que non coñecías. Compara o resolvedor informado co que configurou o paso 2 e compara o resultado co obxectivo do paso 1.

Se o obxectivo era manter as consultas lonxe da rede local, unha proba que mostra o teu resolvedor habitual é un achado real. Se o obxectivo era o anonimato ao navegar, ningún axuste de DNS o tería entregado nunca.

Escribe a liña de aceptación na lingua do obxectivo: estas buscas usan este resolvedor verificado baixo estas condicións. Calquera cousa máis ampla é unha afirmación que non podes probar.