El problema del control de claves en DNS: por qué los protocolos cifrados necesitan una mejor distribución de llaves

Hay algo frustrante en depender de un sistema que, en teoría, debería protegerte pero que en la práctica depende de que nadie te impida llegar a él.

Los protocolos de DNS cifrado como DNS-over-HTTPS (DoH) y DNS-over-TLS (DoT) nacieron para cerrar una brecha histórica: que cualquiera que controle la red pueda ver o alterar las consultas de dominio. La idea era simple: cifrar el tráfico DNS para que nadie supiera qué sitios estás visitando.

Sin embargo, el cifrado solo funciona si puedes usarlo. Y ahí es donde empieza el verdadero problema.

Cuando el bloqueo ya no se centra en romper el cifrado, sino en impedir el acceso a las claves

Los métodos tradicionales de censura digital consisten en bloquear directamente el contenido. Pero algunos gobiernos han optado por una estrategia más sutil: impedir que los usuarios obtengan las claves criptográficas necesarias para establecer la conexión cifrada.

Este cambio se hizo evidente en China en 2021. Los usuarios que intentaban usar DNS cifrado notaron que las consultas no fallaban de forma permanente. En su lugar, funcionaban durante unos segundos y luego quedaban bloqueadas temporalmente. Era un patrón diseñado para generar frustración, no para cortar el acceso por completo.

Al analizar estos comportamientos, quedó claro que el sistema de censura había evolucionado:

• DNS sin cifrado: sigue siendo manipulado con respuestas falsas.
• DNS-over-TLS (puerto 853): se bloquea directamente.
• DNS-over-HTTPS (puerto 443): se permite la conexión, pero se interrumpe de forma intermitente. El resultado práctico es el mismo: el servicio se vuelve inútil.

El problema estructural

Este tipo de ataques pone en evidencia una debilidad de fondo: hemos construido sistemas de privacidad que dependen de distribuir claves públicas a través de internet, pero no hemos resuelto cómo hacerlo cuando alguien controla la infraestructura de red.

El caso de Encrypted Client Hello (ECH) lo ilustra bien. Este protocolo busca ocultar el nombre del dominio al que te conectas cifrando el campo SNI durante el handshake TLS. Pero para usarlo, el navegador necesita primero obtener las claves públicas a través de DNS. Si esa consulta puede ser interceptada, el cifrado nunca llega a aplicarse.

Es una contradicción difícil de resolver: para usar DNS cifrado, primero necesitas hacer una consulta DNS que, sin protección, puede ser manipulada.

Lo que esto significa para desarrolladores y operadores de plataformas

Si gestionas dominios o infraestructura web, este escenario obliga a revisar varias suposiciones comunes:

• Tus registros DNS están disponibles en todas partes. En algunos países o redes, eso no es cierto.
• Los protocolos cifrados eliminan la exposición. Protegen el contenido de la consulta, pero no garantizan que puedas hacerla.
• La censura requiere bloquear por completo. En muchos casos basta con introducir fricción suficiente para que el usuario abandone.

Posibles caminos hacia adelante

Ante este problema, la comunidad técnica está explorando varias estrategias:

• Distribución descentralizada de claves, mediante DNSSEC o sistemas basados en blockchain.
• Ofuscación del tráfico, para que las consultas cifradas sean indistinguibles del tráfico HTTPS normal.
• Redes anycast y distribución geográfica, que complican el bloqueo selectivo de puntos de conexión.
• Soluciones integradas en la aplicación, que reducen la dependencia del sistema DNS.

Ninguna de estas opciones es perfecta. Todas implican compromisos entre rendimiento, facilidad de uso y complejidad técnica.

La lección principal

La infraestructura de privacidad no existe en el vacío. Depende de cómo esté organizada la red, de las decisiones políticas y de la capacidad de quienes controlan el acceso para adaptarse.

Al diseñar cualquier servicio que busque proteger la privacidad —ya sea la gestión de dominios, una API o una aplicación dirigida a usuarios—, hay que considerar qué pasaría si alguien con control de red intentara impedir su uso. Y, sobre todo, qué mecanismos existen para responder a esa situación.

El problema del control de claves en DNS sigue abierto. Las soluciones que surjan probablemente serán más fragmentadas, más distribuidas y requerirán mayor conciencia por parte de los usuarios. Esa no es una limitación del sistema: es simplemente la realidad de construir privacidad en un entorno donde sigue siendo un objetivo en disputa.