DNSSEC o una VPN: quina amaga les teves consultes DNS?

Dos mecanismes reben el mateix encàrrec i cap dels dos el compleix. DNSSEC respon si les dades que has rebut provenen realment de la zona que les publica, i una VPN decideix quin camí segueixen els teus paquets. Cap dels dos amaga el nom que has demanat en tots els casos, i la configuració que sembla que ho hauria de fer normalment tracta del transport o de l’encaminament, no de la validació. Posar nom a la capa primer converteix una pregunta vaga sobre privacitat en una de concreta.

Tres afirmacions que es fonen en una

L’autenticitat és l’afirmació que la resposta és la que va publicar la zona i que no s’ha alterat pel camí. La confidencialitat és l’afirmació que ningú del camí pot llegir la consulta ni la resposta. L’encaminament és l’afirmació que els paquets segueixen un camí que tu has triat, que és el que ofereix un túnel.

DNSSEC tracta la primera i no diu res de les altres dues. DoT i DoH tracten la segona per al salt fins al resolutor. Una VPN tracta la tercera i també pot afectar la segona, però només com a efecte secundari d’on va el trànsit.

El trànsit d’aplicacions és un quart cas: HTTPS protegeix i autentica l’intercanvi web entre el teu client i el lloc, i cap capa DNS el substitueix.

Què pot i què no pot fer la validació de signatures

Un resolutor validador comprova la cadena de signatures des de la zona fins a un ancoratge de confiança configurat i després retorna una resposta amb la marca de dades autenticades activada quan la comprovació té èxit. Aquesta marca és una prova sobre les dades, no sobre la connexió ni sobre les intencions de la destinació.

No pot impedir que un propietari legítim d’una zona publiqui registres autèntics per a un servei en què no hauries de confiar. Una resposta correctament signada d’un domini compromès continua estant correctament signada, i DNSSEC no opina si aquest domini mereix les teves credencials.

Tampoc no amaga res. La consulta i la resposta travessen la xarxa en una forma que el resolutor i qualsevol observador d’aquell camí poden llegir, tret que una altra capa protegeixi el transport. Una resposta signada i una resposta privada són propietats diferents, i un desplegament pot tenir-ne només una. Prova les dues si alguna t’importa.

D’on ve realment la confidencialitat

El transport xifrat fins al resolutor embolcalla l’intercanvi DNS en TLS, així que el resolutor continua veient la pregunta però el camí entre tu i ell no. Això mou la confiança en lloc d’eliminar-la: confies més en el resolutor i menys en la xarxa local.

Una VPN pot portar les consultes a un resolutor de l’altra banda, cosa que canvia tant el camí com el resolutor que les veu. És una decisió d’encaminament amb una conseqüència per a la privacitat, i en una xarxa gestionada el resolutor intern pot ser l’únic que pot respondre noms interns.

La combinació que la gent vol de veritat solen ser tres coses alhora: validació activada, transport xifrat fins a un resolutor triat per ells i TLS de l’aplicació a la destinació. Cadascuna és independent, i saltar-se’n una deixa un forat diferent.

Comprova la validació i el transport per separat

Dues proves resolen la major part del desconcert. La primera pregunta si el resolutor ha validat la resposta; la segona, si el transport estava protegit. Falles de maneres diferents i cap no implica l’altra.

Aquestes ordres imprimeixen les marques d’una consulta validadora, repeteixen la consulta amb la comprovació desactivada i executen la validació local amb delv:

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

Una resposta amb la marca de dades autenticades i una signatura present mostra validació en aquell resolutor. Un error de validació amb delv mostra una cadena trencada en algun punt entre la zona i l’ancoratge de confiança, que és un problema de publicació, no un problema de túnel. Un temps d’espera sense cap marca és un problema de transport o d’abast, i tractar-lo com un error de signatura et porta a la capa equivocada.

Què fer quan una VPN trenca les consultes

Si les consultes funcionaven abans del túnel i s’aturen després, compara el resolutor que fa servir cada camí. El tunelatge dividit, un resolutor intern només abastable a través del túnel i un client que reescriu la configuració del resolutor canvien la resposta sense tocar DNSSEC.

Desactivar la validació globalment és el primer moviment equivocat, perquè elimina l’únic mecanisme que informa de manipulacions i no arregla un resolutor que no es pot assolir. Estreny primer la fallada: resolució, transport, validació i després política. Només la tercera pertany a DNSSEC, i només la segona pertany al transport xifrat.