DNSSEC o una VPN: ¿cuál oculta tus consultas DNS?

Dos mecanismos reciben el crédito por la misma tarea y ninguno de los dos la realiza. DNSSEC responde si los datos que recibiste proceden realmente de la zona que los publica, y una VPN decide por qué camino van tus paquetes. Ninguno de los dos oculta en todos los casos el nombre que preguntaste, y los ajustes que parecen deberían hacerlo suelen tratar del transporte o del enrutamiento y no de la validación. Nombrar primero la capa convierte una pregunta vaga sobre privacidad en una concreta.

Tres afirmaciones que se funden en una

La autenticidad es la afirmación de que la respuesta es la que publicó la zona y no se alteró en el camino. La confidencialidad es la afirmación de que nadie en el camino puede leer la consulta ni la respuesta. El enrutamiento es la afirmación de que los paquetes siguen un camino que elegiste tú, que es justo lo que ofrece un túnel.

DNSSEC aborda la primera y no dice nada de las otras dos. DoT y DoH abordan la segunda para el salto hasta el resolutor. Una VPN aborda la tercera y también puede afectar a la segunda, pero solo como efecto secundario de hacia dónde va el tráfico.

El tráfico de aplicaciones es un cuarto caso: HTTPS protege y autentica el intercambio web entre tu cliente y el sitio, y ninguna capa DNS lo sustituye.

Qué puede y qué no puede hacer la validación de firmas

Un resolutor validador comprueba la cadena de firmas desde la zona hasta un ancla de confianza configurada y luego devuelve una respuesta con el indicador de datos autenticados activado cuando la comprobación tiene éxito. Ese indicador es una prueba sobre los datos, no sobre la conexión ni sobre las intenciones del destino.

No puede impedir que un propietario legítimo de una zona publique registros auténticos para un servicio en el que no deberías confiar. Una respuesta correctamente firmada de un dominio comprometido sigue estando correctamente firmada, y DNSSEC no opina sobre si ese dominio merece tus credenciales.

Tampoco oculta nada. La consulta y la respuesta cruzan la red en una forma que un resolutor y cualquier observador de ese camino pueden leer, salvo que otra capa proteja el transporte. Una respuesta firmada y una respuesta privada son propiedades distintas, y un despliegue puede tener solo una de ellas. Prueba ambas si alguna te importa.

De dónde viene realmente la confidencialidad

El transporte cifrado hasta el resolutor envuelve el intercambio DNS en TLS, así que el resolutor sigue viendo la pregunta pero el camino entre tú y él no. Eso mueve la confianza en lugar de eliminarla: confías más en el resolutor y menos en la red local.

Una VPN puede llevar las consultas a un resolutor del otro lado, lo que cambia tanto el camino como el resolutor que las ve. Es una decisión de enrutamiento con una consecuencia para la privacidad, y en una red gestionada el resolutor interno puede ser el único que puede responder nombres internos.

La combinación que la gente quiere de verdad suele ser tres cosas a la vez: validación activada, transporte cifrado hasta un resolutor que hayan elegido y TLS de la aplicación en el destino. Cada una es independiente, y saltarse una deja un hueco distinto.

Comprueba la validación y el transporte por separado

Dos pruebas resuelven la mayor parte de la confusión. La primera pregunta si el resolutor validó la respuesta; la segunda, si el transporte estaba protegido. Fallan de maneras distintas y ninguna implica la otra.

Estos comandos imprimen los indicadores de una consulta validadora, repiten la consulta con la comprobación desactivada y ejecutan la validación local con delv:

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

Una respuesta con el indicador de datos autenticados y una firma presente muestra validación en ese resolutor. Un fallo de validación con delv muestra una cadena rota en algún punto entre la zona y el ancla de confianza, que es un problema de publicación y no un problema de túnel. Un tiempo de espera sin ningún indicador es un problema de transporte o de alcance, y tratarlo como un fallo de firma te lleva a la capa equivocada.

Qué hacer cuando una VPN rompe las consultas

Si las consultas funcionaban antes del túnel y se detienen después, compara el resolutor que usa cada camino. El tunelado dividido, un resolutor interno solo accesible a través del túnel y un cliente que reescribe la configuración del resolutor cambian la respuesta sin tocar DNSSEC.

Desactivar la validación globalmente es el primer movimiento equivocado, porque elimina el único mecanismo que informa de manipulación y no arregla un resolutor al que no se puede llegar. Acota primero el fallo: resolución, transporte, validación y luego política. Solo la tercera pertenece a DNSSEC, y solo la segunda pertenece al transporte cifrado.