Introducción
El 22 de octubre de 2026, la fundación suiza Quad9 anunció su retirada de Francia, efectiva el 24 de noviembre. El detonante: una sentencia del tribunal civil de París que ordenaba a este resolvedor DNS bloquear una cincuentena de dominios vinculados a la retransmisión ilícita de partidos de tenis, a instancias de beIN Sports. La fundación se negó a cumplirla —no por postura ideológica, sino por una razón estrictamente arquitectónica: sencillamente no dispone de los datos necesarios para ejecutar un bloqueo geográficamente selectivo.
Un bloqueo territorial que exige datos que Quad9 nunca tuvo
Quad9 opera un resolvedor DNS público accesible en la dirección 9.9.9.9, gratuito y sin registro de usuarios. Precisamente ese diseño hace que la orden judicial sea imposible de cumplir. Identificar a los usuarios franceses para bloquearles selectivamente ciertos dominios requiere, como mínimo, un mecanismo de geolocalización de consultas y una base de correspondencia IP/territorio. Pero Quad9 construyó su modelo sobre la ausencia total de ese tipo de dato: sin registros de direcciones IP, sin perfiles de usuario, sin trazabilidad de consultas. Es una decisión de arquitectura deliberada, reivindicada como garantía de privacidad y compatible con el RGPD.
La alternativa —bloquear los dominios en cuestión para toda su base global de usuarios— fue descartada por desproporcionada. Antes que construir desde cero una base de datos que siempre se negó a constituir, o aplicar un bloqueo planetario por orden de un tribunal nacional, Quad9 optó por dejar de operar en territorio francés. La penalización inicial solicitada por beIN Sports ascendía a 580 000 € por día; el tribunal la redujo a 1 000 € por día. Ello no modificó la decisión de la fundación, que afronta además una veintena de procedimientos judiciales franceses en curso.
Lo que la capa DNS revela sobre su gobernanza de datos
Este caso no es un episodio judicial aislado. Pone de manifiesto una categoría de decisiones que muchos equipos de TI nunca formalizan: la elección del resolvedor DNS.
El DNS es la primera capa de cualquier conexión de red. Cada pipeline de datos, cada llamada a una API de terceros, cada sincronización SaaS pasa primero por una resolución de nombre. Quién gestiona esa resolución, qué datos conserva y bajo qué jurisdicción opera son preguntas con implicaciones directas sobre la soberanía de los datos operativos de la organización.
Quad9 era utilizado por redes institucionales —sanidad, educación, administraciones públicas, energía— por dos propiedades simultáneas: un filtrado activo de dominios maliciosos alimentado por más de veinticinco proveedores de inteligencia de amenazas, y una ausencia total de registros de usuarios. Su salida de Francia genera un vacío funcional para estas organizaciones, que deberán migrar a otro resolvedor o desplegar uno propio.
Tres preguntas que hacerle a su infraestructura DNS
¿Su resolvedor actual recopila datos? Muchos equipos desconocen si su resolvedor registra las consultas, las almacena localmente o las transfiere a un tercero. Sin embargo, se trata de datos operativos sobre la totalidad de los flujos aplicativos —datos que raramente aparecen en los registros de tratamiento de información.
¿Cuál es su dependencia real de un servicio externo? Si un resolvedor público desaparece o cambia su política, ¿cuántos sistemas conmutan silenciosamente a un fallback no documentado?
¿Cómo encaja su DNS con su estrategia de soberanía digital? La Unión Europea lanzó DNS4EU en 2025, un resolvedor conforme con los requisitos regulatorios europeos. Las soluciones on-premise permiten mantener el control total sobre los registros y las reglas de filtrado, a costa de una gestión operativa internalizada.
El caso Quad9 ilustra una tensión cada vez más frecuente en la gobernanza de datos: las arquitecturas diseñadas para minimizar la recopilación son eficaces desde el punto de vista de la privacidad, pero pueden chocar con obligaciones legales que presuponen precisamente la existencia de esos datos. Es un equilibrio que los CIOs y los responsables de datos deben documentar de forma explícita —y no dejar cristalizado por defecto en una configuración de red heredada.