DNSSEC ou unha VPN: cal oculta as túas consultas DNS?

Dous mecanismos reciben o mesmo encargo e ningún dos dous o cumpre. DNSSEC responde se os datos que recibiches proveñen realmente da zona que os publica, e unha VPN decide por que camiño van os teus paquetes. Ningún dos dous oculta en todos os casos o nome que preguntaches, e os axustes que parecen que deberían facelo adoitan tratar do transporte ou do enrutamento e non da validación. Nomear primeiro a capa converte unha pregunta vaga sobre privacidade nunha concreta.

Tres afirmacións que se funden nunha

A autenticidade é a afirmación de que a resposta é a que publicou a zona e non se alterou polo camiño. A confidencialidade é a afirmación de que ninguén no camiño pode ler a consulta nin a resposta. O enrutamento é a afirmación de que os paquetes seguen un camiño que escolliches ti, que é xusto o que ofrece un túnel.

DNSSEC aborda a primeira e non di nada das outras dúas. DoT e DoH abordan a segunda para o salto ata o resolutor. Unha VPN aborda a terceira e tamén pode afectar a segunda, pero só como efecto secundario de cara a onde vai o tráfico.

O tráfico de aplicacións é un cuarto caso: HTTPS protexe e autentica o intercambio web entre o teu cliente e o sitio, e ningunha capa DNS o substitúe.

Que pode e que non pode facer a validación de sinaturas

Un resolutor validador comproba a cadea de sinaturas desde a zona ata unha áncora de confianza configurada e logo devolve unha resposta co indicador de datos autenticados activado cando a comprobación ten éxito. Ese indicador é unha proba sobre os datos, non sobre a conexión nin sobre as intencións do destino.

Non pode impedir que un propietario lexítimo dunha zona publique rexistros auténticos para un servizo no que non deberías confiar. Unha resposta correctamente asinada dun dominio comprometido segue estando correctamente asinada, e DNSSEC non opina sobre se ese dominio merece as túas credenciais.

Tampouco oculta nada. A consulta e a resposta atravesan a rede nunha forma que un resolutor e calquera observador dese camiño poden ler, salvo que outra capa protexa o transporte. Unha resposta asinada e unha resposta privada son propiedades distintas, e unha implantación pode ter só unha delas. Proba ambas se algunha che importa.

De onde vén realmente a confidencialidade

O transporte cifrado ata o resolutor envolve o intercambio DNS en TLS, así que o resolutor segue vendo a pregunta pero o camiño entre ti e el non. Iso move a confianza en lugar de eliminala: confías máis no resolutor e menos na rede local.

Unha VPN pode levar as consultas a un resolutor do outro lado, o que cambia tanto o camiño como o resolutor que as ve. É unha decisión de enrutamento cunha consecuencia para a privacidade, e nunha rede xestionada o resolutor interno pode ser o único que pode responder nomes internos.

A combinación que a xente quere de verdade adoita ser tres cousas á vez: validación activada, transporte cifrado ata un resolutor que elixiran e TLS da aplicación no destino. Cada unha é independente, e saltarse unha deixa un oco distinto.

Comproba a validación e o transporte por separado

Dúas probas resolven a maior parte da confusión. A primeira pregunta se o resolutor validou a resposta; a segunda, se o transporte estaba protexido. Fallan de maneiras distintas e ningunha implica a outra.

Estes comandos imprimen os indicadores dunha consulta validadora, repiten a consulta coa comprobación desactivada e executan a validación local con delv:

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

Unha resposta co indicador de datos autenticados e unha sinatura presente mostra validación nese resolutor. Un fallo de validación con delv mostra unha cadea rota nalgún punto entre a zona e a áncora de confianza, que é un problema de publicación e non un problema de túnel. Un tempo de espera sen ningún indicador é un problema de transporte ou de alcance, e tratalo como un fallo de sinatura lévao á capa equivocada.

Que facer cando unha VPN rompe as consultas

Se as consultas funcionaban antes do túnel e detéñense despois, compara o resolutor que usa cada camiño. O tunelado dividido, un resolutor interno só accesible a través do túnel e un cliente que reescribe a configuración do resolutor cambian a resposta sen tocar DNSSEC.

Desactivar a validación globalmente é o primeiro movemento equivocado, porque elimina o único mecanismo que informa de manipulación e non arranxa un resolutor ao que non se pode chegar. Acota primeiro o fallo: resolución, transporte, validación e logo política. Só a terceira pertence a DNSSEC, e só a segunda pertence ao transporte cifrado.