DNS Over HTTPS Se Salta Tus Controles Sin Despeinarse

Hay una forma de que cualquier cosa en tu red resuelva un nombre sin que tu servidor DNS oiga nunca la pregunta. Ningún ajuste cambiado en la máquina, ningún permiso de administrador, nada que encuentres en un registro. La consulta sale como una petición HTTPS normal por el puerto 443, va a un resolver en algún lugar de internet y vuelve con una respuesta que tu propio resolver se habría negado a dar.

La lista de bloqueo nunca salta. El feed de amenazas nunca recibe la consulta. La línea de registro que habrías ido a buscar nunca se escribió.

Se llama DNS over HTTPS, DoH para abreviar, y se construyó por una buena razón. El DNS normal viaja en texto claro por el puerto 53, así que la cafetería, el aeropuerto y tu proveedor de internet pueden leer cada nombre que resuelves y cambiar las respuestas si les apetece. DoH envuelve la consulta en el mismo cifrado que el resto de la web y la esconde entre la multitud. Como medida de privacidad para una persona en una red hostil, hace exactamente lo que dice.

El problema es que aquello que derrota y aquello de lo que dependes son lo mismo.

Tu resolver no es solo un servicio de consulta. Es un punto de control: donde un dominio conocido como malo se responde con nada, donde una consulta a un servidor de mando aparece en un registro, donde Protective DNS rechaza el dominio de malware antes de que se establezca la conexión. DoH le quita la consulta a tu resolver y se la entrega a uno que nunca elegiste, y todo control que colgaste de ese resolver se va con ella.

Esto no es un argumento contra cifrar el DNS. El DNS cifrado es lo correcto, y la última sección de este artículo es cómo hacerlo. Es un argumento sobre quién puede elegir el resolver, porque esa elección es toda la partida, y DoH se diseñó para quitártela y dársela al navegador, a la app y, si no tienes cuidado, al atacante.

Qué Es DoH En Realidad

Quítale la marca y DoH es una petición web normal que resulta llevar una pregunta DNS.

El DNS normal es un pequeño mensaje binario enviado por UDP o TCP al puerto 53. DoH mete ese mismo mensaje, o una versión JSON de él, dentro de una petición HTTPS a un servidor web que habla el protocolo; la respuesta es una respuesta HTTPS¹. Esa es la idea entera.

RFC 8484 lo estandarizó en octubre de 2018, y la intención nunca se ocultó. El objetivo, dice su propia introducción, es «allowing web applications to access DNS information via existing browser APIs»¹.

APIs de navegador existentes. Una página web. Nadie descubrió eso como un efecto secundario incómodo años después. Está en el primer párrafo del estándar, escrito como el objetivo.

Aquí tienes una consulta hecha a la manera DoH, desde la línea de comandos, contra un resolver público, pidiendo example.com:

$ curl -s -H 'accept: application/dns-json' \
    'https://cloudflare-dns.com/dns-query?name=example.com&type=A'
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":true,"CD":false,
 "Question":[{"name":"example.com","type":1}],
 "Answer":[{"name":"example.com","type":1,"TTL":146,
            "data":"23.192.228.80"}]}

Ningún cliente especial. Ningún puerto salvo el 443. Una sola petición HTTPS, con la misma forma que cargar una página web, y un nombre resuelto por una máquina al otro lado del mundo que nunca ha oído hablar de tu red ni de tus reglas. Google opera el mismo endpoint, también Quad9, y decenas más.

Ahora mira lo que ve tu cortafuegos. Una conexión TLS a un servidor web en el 443, que no puede leer por dentro porque ese es el sentido de TLS, y que no puede distinguir de los cientos de otras que se abren cada segundo hacia redes de distribución de contenido, analíticas y anuncios. La pregunta DNS ha desaparecido. Salió del edificio vestida de tráfico web y nadie en la puerta pudo verle la cara.

Hay tres formas en que un cliente puede mover una consulta DNS, y vale la pena ponerlas una al lado de la otra, porque la diferencia es todo el artículo.

El DNS normal es legible y bloqueable, y por eso mismo era fácil de controlar y fácil de espiar. DoT cifra la consulta pero conserva su propio puerto, así que aún puedes rechazarla en la frontera. DoH es el que no tiene asa: cifrado como DoT, pero compartiendo el único puerto que nunca puedes cerrar, así que la única palanca que queda es qué resolver eligió el cliente, y de esa palanca trata este artículo.

Quién Elige El Resolver

Esto importa porque una máquina moderna tiene cinco cosas distintas que pueden decidir cada una adónde va el DNS, y tú controlas exactamente una de ellas por defecto.

El sistema operativo pregunta al resolver que tu red repartió por DHCP o por anuncios de router. Ese es tuyo, y es el modelo que asumió todo lo anterior a 2019 más o menos: un resolver, repartido por la red, y por eso los controles DNS a nivel de red funcionaron durante treinta años.

El navegador lo rompió. Firefox y Chrome ambos incorporan la maquinaria para hacer su propio DoH, hacia un resolver que eligió su fabricante, por encima de ti, retirándose solo cuando detectan una red gestionada. Y una aplicación puede llevar su propio cliente DoH y un resolver fijado en su código, decidido en tiempo de compilación; no lee tu DHCP ni pregunta. Mucho software legítimo ya lo hace.

Un script en una página web es el que debería detenerte, porque no necesita nada instalado en absoluto. Aquel comando curl de arriba es una sola petición HTTPS, y un navegador se gana la vida haciendo peticiones HTTPS. Unas pocas líneas de JavaScript en cualquier página que un usuario abra pueden enviar consultas a un endpoint DoH público, porque los grandes proveedores permiten deliberadamente peticiones de origen cruzado para que las apps web puedan usarlos, el objetivo declarado en RFC 8484. La página que estás leyendo podría resolver nombres a través de un resolver en otro país ahora mismo y tú verías una conexión HTTPS más.

Y el malware elige su propio resolver por la razón evidente: no quiere que veas adónde está llamando. Lleva el resolver en su código, a menudo alcanzándolo por dirección para que no haya consulta de arranque que atrapar, y no necesita tu permiso para nada de ello.

Lee esa columna otra vez. Las tres de abajo no necesitan permisos de administrador, ni un ajuste cambiado, ni nada que se vea en el sistema operativo. El control que tardaste años en construir, un resolver, una lista de bloqueo, un registro, asumía que la fila de arriba era la única fila. No lo es desde hace años.

El Mismo Truco Que Temían Los Fabricantes De Navegadores

El caso de la página web no es teórico ni reciente. Es cómo se abusa de los ayudantes de protocolo: una página web emite bytes, algo aguas abajo actúa sobre ellos, y no puede saber si vinieron de la página de un atacante o de un cliente real, porque en el cable son idénticos. Con DoH la pieza de aguas abajo es un resolver público, que responde sin forma de saber que el JavaScript que pregunta vino de una página de phishing, y tu resolver, el que tiene la lista de bloqueo y el registro, nunca estuvo en el camino para opinar. No un agujero abierto a la fuerza en tus controles, sino un camino construido alrededor de ellos, pavimentado con el mismo cifrado que le dices a todo el mundo que use.

Ya Es El Canal Del Autor De Malware

No tienes que imaginar cómo se usa esto. Está documentado desde hace años, por investigadores con nombre, sobre muestras reales, y la dirección del viaje es una sola: de bot criminal en 2019 a herramienta de inteligencia estatal al año siguiente, y más concurrida cada año desde entonces, con puertas traseras nuevas aún apareciendo en 2026.

Godlua, el primer caso ampliamente reportado, fue una puerta trasera para Linux y Windows cuyo análisis recoge que «uses DNS over HTTPS to get the C2 name to ensure secure communication between the bots, the Web Server and the C2»². En una red vigilando el puerto 53, resolver tu servidor de mando es un regalo para el defensor. Sobre DoH no hay nada que observar.

La frase de Proofpoint sobre PsiXBot es la que vale la pena citar, un proveedor de inteligencia de amenazas diciendo en voz alta lo que se calla. Usar DoH para mando y control, escribieron, «should be a warning shot for the cybersecurity community as there are no simple solutions to help identify an infected host or the process of receiving instructions»³. Ninguna solución sencilla, de parte de la gente cuyo trabajo es encontrarlas.

Luego OilRig lo llevó a otro nivel. La descripción de Kaspersky es exactamente el cambio del que trata este artículo: «instead of plain text requests to port 53, they would use port 443 in encrypted packets», con una herramienta que «allows DoH queries to Google and Cloudflare services»⁴. Una operación de inteligencia nacional, usando los proveedores DoH públicos como la tubería para sacar datos robados por delante de lo que fuera que vigilaba el DNS.

Y no se detuvo ahí. Se extendió. Para 2023 ChamelGang tenía una puerta trasera para Linux en C++, ChamelDoH, que llevaba todo su canal de mando por DoH, enviando consultas TXT de DNS a sus propios servidores de nombres a través de Google y Cloudflare; el investigador que la encontró señaló que tanto la detección como la prevención «become difficult», porque el transporte cifrado no puede interceptarse y una petición maliciosa no puede distinguirse de una real⁵. En diciembre de 2025 CISA desmontó BRICKSTORM, una puerta trasera de nexo con China que apila HTTPS, WebSockets y TLS anidado y «also uses DNS-over-HTTPS (DoH)» para enterrar su C2 en tráfico web corriente⁶. Para febrero de 2026 ya era pura rutina: Cisco Talos cazó a Dohdoor, que «securely sends encrypted DNS requests to Cloudflare’s DNS server over HTTPS port 443» para encontrar su servidor de mando, colándose por phishing en escuelas y hospitales estadounidenses⁷.

Esa es la forma del asunto. No una técnica que tuvo su momento y se apagó, sino una que cae en más manos cada año. El problema va a peor, no a mejor, y una familia nueva aparece ahora puntualmente.

Una sola propiedad hizo el trabajo en todos ellos: la consulta salió como HTTPS por el 443 y el resolver del defensor nunca la vio. No una debilidad que alguien podría encontrar algún día. Una característica que los atacantes han distribuido una y otra vez, varios de ellos Estados.

Y hay que tener claro por qué esa tabla se llena, año tras año. Cada familia que hay en ella cruza una puerta que a los autores de DoH les advirtieron que estaban dejando abierta, en el propio texto del estándar, y la dejaron abierta igualmente⁸. Eso no fue un descuido. Fue miopía, elegida a propósito, por gente que incluía al propio tecnólogo de ICANN. Así que lo llamaré por su nombre: en esto, ICANN son facilitadores de la ciberdelincuencia. Advertidos en el propio texto del estándar de qué se rompería, aun así su propia gente lo firmó, y la tabla de arriba es lo que cruzó por la brecha. El crimen no es ninguna sorpresa. Es la factura de una decisión, y de quién fue esa decisión trata el resto de este artículo.

Y con todo eso, DoH ni siquiera compra lo que la gente supone: protección frente a una respuesta falsificada. Cifrar el salto hasta un resolver no es autenticar lo que el resolver devuelve, y un servidor DoH aún puede devolver un registro falsificado. El estándar lo admite, diciendo que la regla contra servidores no configurados «does not guarantee protection against invalid data»⁹.

El único mecanismo que autentica una respuesta DNS es DNSSEC, y DoH no lo es. Peor aún, para casi todos los clientes DNSSEC se valida en el resolver recursivo, no en el dispositivo: el cliente simplemente se fía de la palabra del resolver de que la respuesta cuadró. Así que DNSSEC solo te protegió hasta donde te fiabas del resolver que hacía la comprobación, y la jugada real de DoH es entregar esa confianza a un operador remoto que no puedes ver ni auditar.

Como tal, DoH puede dejarte más expuesto a caer en un sitio falsificado, no menos: las defensas locales que habrían atrapado una respuesta secuestrada, el feed de Protective DNS, el filtrado del propio operador, son justo las cosas que rodeaste, y lo único que queda es la palabra de un operador remoto, tomada por fe.

Y nada de esto es una idea nueva con la que DoH tropezó por accidente. Filtrar dominios maliciosos en el resolver es exactamente lo que OpenDNS lleva haciendo cerca de veinte años, bloqueando phishing y malware para millones de usuarios antes de que la respuesta llegara siquiera, que es el modelo que Cisco pagó por poseer en 2015¹⁰. Dos décadas de seguridad a nivel de resolver que protegió a gente que nunca configuró nada, y DoH socavó todo el modelo de un solo golpe: apunta la app a su propio resolver, y OpenDNS, o lo que fuera que tu red eligiera, ya no está en el camino.

Por Qué La Respuesta De Antes Dejó De Funcionar

Mientras el DNS vivió en el puerto 53, la respuesta de red era simple. Obliga a cada cliente a usar tu resolver, y bloquea el puerto 53 saliente hacia cualquier otro sitio en la frontera. Una máquina que buscara un servidor DNS externo era rechazada, así que tenía que pasar por el tuyo, así que tus controles se aplicaban a todo. Rudimentario, y funcionaba.

DoH mata eso de un movimiento usando el 443. No puedes bloquear el 443 saliente. Es la web. Así que el puerto que cerrarías para forzar el DNS por tu resolver es el único que nunca puedes cerrar, y el cifrado que impide que tu ISP fisgonee te impide también distinguir una consulta DoH de una carga de página.

Las dos cosas que usarías para recuperar el control, cerrar el puerto y leer el tráfico, se han ido las dos por diseño. Derrotar exactamente esas dos, en manos de una red hostil, es para lo que se construyó DoH.

Y leer el tráfico no es la escapatoria que parece, porque solo hay una forma de hacerlo: romper e inspeccionar todo. Para ver el DNS dentro de una conexión 443 tienes que hacer de hombre en el medio en cada conexión HTTPS de la red, poner tu propio certificado raíz en cada dispositivo, y descifrar y recifrar todo. Eso es a lo que un número creciente de administradores recurre ahora, para arañar la visibilidad que una sola regla de cortafuegos les daba gratis.

Y es un trato mucho peor: has debilitado TLS para todo, has puesto una caja de descifrado en el camino de cada inicio de sesión y cada operación bancaria, y has construido un único blanco que compromete todo ello, una postura contra la que US-CERT advirtió sin rodeos¹¹. El control proporcionado se rompió, así que el desproporcionado es lo que queda.

Y ahí está la encerrona. El mecanismo que protege a un periodista en el WiFi de un aeropuerto de una red hostil es el que protege al malware de tu red de ti, y el protocolo no puede distinguir los dos casos. Un resolver que está siendo rodeado no sabe si es un censor o un equipo de seguridad. Solo sabe que lo han dejado fuera.

La Respuesta Correcta Siempre Fue DNS Over TLS

Aquí está la parte que lo delata. Cifrar el DNS nunca necesitó nada de esto. Se hizo dos años antes que DoH, de una manera que dejaba a quien lleva la red capaz de hacer su trabajo.

DNS over TLS, RFC 7858, es de mayo de 2016. Su resumen dice para qué es en la primera línea: «provide privacy for DNS», cifrado que «eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network»¹². Ese es el caso de la privacidad entero, resuelto: la cafetería y el ISP quedan fuera exactamente igual que con DoH, porque la consulta va cifrada de extremo a extremo.

Y lo coescribió Paul Hoffman, que después coescribió también el estándar DoH¹. No dos bandos rivales, entonces. La misma gente, que ya había resuelto la privacidad, resolviéndola otra vez de otra forma.

Quién es Hoffman importa, porque dice de dónde vino esto. No es un espectador en el DNS: su nombre está en más de ochenta RFC, entre ellos el estándar de terminología DNS, y hace el trabajo como tecnólogo en ICANN¹³. Así que el estándar que escondió el DNS en el 443 se coescribió desde dentro de ICANN, el organismo estadounidense que decide qué va en la raíz.

E ICANN no es el custodio desinteresado que la palabra sugiere. He expuesto su historial por separado: construido en California, sujeto a California, y dispuesto a usar su posición sobre el espacio de nombres para sus propios fines. Esto no fue una campaña de privacidad desde la periferia. Fue el establishment que sostiene la raíz, resolviendo por segunda vez un caso de privacidad que ya había resuelto en 2016, de una manera que quitó de en medio al operador de red.

Así que pregúntate qué añadió la segunda forma, porque la privacidad no fue.

La única casilla que cambió es la última. DoT corre en su propio puerto, el 853, así que el operador puede ver que es DNS y decidir qué le pasa: permitirlo hacia el resolver autorizado, rechazarlo en otro sitio. DoH pone la misma consulta cifrada en el 443 y la mezcla con la web, donde el operador no puede distinguirla.

Misma privacidad, mismo cifrado. La única diferencia entre los dos estándares es si quien lleva la red aún puede ver su propio DNS. Eso no es una característica de privacidad. La privacidad se entregó en 2016. Es una característica de evasión, y es lo único que DoH añade.

Y lo sabían. Esto está documentado, no inferido. Las propias Operational Considerations de RFC 8484 lo dicen sin rodeos: «Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment due to the confidentiality and integrity protection provided by TLS»⁸.

Esos sistemas son las herramientas de seguridad que ya protegían a los usuarios: bloqueo de malware y de servidores de mando, feeds de Protective DNS, filtros de protección infantil, inspección empresarial. El estándar los nombra, en su propio texto, como las cosas que dejan de funcionar. Romper unas herramientas que ya defendían a la gente fue una decisión, tomada con los ojos abiertos y distribuida activada por defecto. Conocer el efecto y elegirlo de todos modos es una decisión de la que se les puede pedir cuentas.

Por eso el encuadre de la privacidad no sobrevive a la cronología. Una vez que DoT existe, la privacidad no puede ser la razón de DoH, porque la privacidad ya estaba hecha, por el mismo autor, dos años antes. Así que la privacidad era la tapadera.

Retírala y mira lo que el segundo estándar puso realmente en marcha: una carrera armamentística. Cogió un control que era una línea de cortafuegos y lo convirtió en una persecución permanente, resolvers contra listas de bloqueo contra resolvers nuevos, el operador perdiendo por defecto, y un puñado de empresas estadounidenses con el texto claro al final de todo.

Llámalo un efecto secundario de una característica de privacidad si quieres. Con las pruebas delante, con DoT ya distribuido y el propio estándar admitiendo que rompería el filtrado, es el objetivo, y la privacidad era la palabra pintada en la caja. Y se empujó con fuerza bajo esa palabra, por las partes que ganaron.

Quienes lo vendían como privacidad eran los fabricantes de navegadores, y los beneficiarios no eran solo los usuarios.

¿Puedo preguntar por qué, si el objetivo era la privacidad, la respuesta no fue el estándar de DNS cifrado que ya existía y mantenía al operador en el bucle, sino un segundo construido para que el operador no pudiera verlo? No pregunto quién lo firmó. Pregunto qué parte de «privacidad» exigía dejar fuera a la única persona responsable de la red.

Porque ese es el verdadero blanco, y es el administrador de red: el profesional responsable de la seguridad y de la protección de la red, tratado como el adversario por defecto. DoH ni siquiera elimina la vigilancia de la que se quejaba el discurso de la privacidad. Como expuso Bert Hubert de PowerDNS, el DNS «typically provided by the operator of a network», y trasladarlo a un tercero por defecto es «a net-negative for privacy for everyone», porque ese tercero «gets a complete log per device of all DNS queries, in a way that can even be tracked across IP addresses»¹⁴.

Las consultas no quedan ocultas. Se entregan a un operador de resolver estadounidense en lugar de al administrador, y el administrador es la única parte que se retira. Los fabricantes lo saben, también. La lógica de «detectar una red gestionada y retirarse» de la siguiente sección existe precisamente porque el comportamiento por defecto pasa por encima del administrador, y distribuyeron el interruptor de apagado en vez de cambiar el comportamiento por defecto.

Ahora pregúntate quién gana con desviar el DNS por delante del operador. El caso de manual es el periodista en el WiFi hostil de un aeropuerto, y esa persona es real. También lo es la industria de la publicidad y el rastreo, cuyos dominios pasan por delante de la lista de bloqueo de una red en cuanto una app o un navegador los resuelve por DoH.

El bloqueo a nivel de red, el Pi-hole, la lista de bloqueo corporativa, el resolver de filtrado, funciona respondiendo con nada al nombre de un rastreador. DoH es como el nombre se responde de todos modos. Y el mayor operador de un resolver DoH público es Google¹⁵, una empresa de publicidad que además distribuye DoH en su propio navegador¹⁶.

Una característica de privacidad, vendida por la empresa que vende el rastreo, cuyo diseño derrota la herramienta que la gente usa para bloquearlo. Piensa lo que quieras de eso. Yo lo tengo claro.

Hasta la versión burda de esta objeción se aireó. En julio de 2019 el organismo de la patronal de ISP del Reino Unido nominó a Mozilla «Internet Villain» por un DoH que «bypass UK filtering obligations and parental controls, undermining internet safety standards in the UK»¹⁷. Escogieron un blanco torpe y un encuadre peor, les cayó la bronca, y la retiraron.

Quita la política, sin embargo, y la observación de debajo era correcta, y se sostiene tanto si el control que se rodea es un filtro de protección infantil, una lista de bloqueo de empresa o un Pi-hole en una habitación libre. DoH está construido para sacar el DNS por delante de quienquiera que lleve la red.

Y no es asunto menor, porque DoH es ahora el más difícil de los tres de bloquear siquiera. DoT está en el 853, donde una red aún puede rechazarlo. DoH no, así que de todas las formas en que el DNS puede salir de una red es la única sin asa, lo que lo convierte en el mayor riesgo individual de todos.

Eso alcanza a la ley, no solo a la seguridad. En el Reino Unido el bloqueo que tiene peso legal se hace en el ISP por DNS: la lista de la Internet Watch Foundation de material de abuso sexual infantil, y las órdenes de bloqueo por derechos de autor que el High Court dicta bajo el artículo 97A, se aplican mediante filtrado de DNS e IP en el resolver que se entrega al cliente¹⁸.

Desvía por DoH la mitad de DNS de eso y el bloqueo no se aplica a ese cliente. Un tribunal puede ordenar el bloqueo de un sitio, se le puede decir a una red que lo aplique, y un navegador que resuelve por DoH encuentra la dirección de todos modos, por un canal que la red no puede ver ni cerrar. Aplicar una ley de ciberseguridad o una orden judicial a nivel de red, que es donde siempre se ha aplicado, se vuelve casi imposible.

Y aquí es donde la factura cae sobre todos, no solo sobre la red. Rompe el control proporcionado, el quirúrgico que bloqueaba un dominio con nombre en el resolver bajo una orden judicial, y el Estado no se rinde. Echa mano de un instrumento más romo. La Online Safety Act del Reino Unido es ese instrumento: deberes amplios sobre las plataformas, verificación de edad obligatoria, y Ofcom detrás con las multas, un régimen que toca a cada usuario y cada servicio del país¹⁹.

No estoy defendiendo la ley. Estoy señalando de dónde vino la presión que la trajo. Cuando la herramienta estrecha que aplicaba la ley en la red deja de funcionar, no obtienes menos aplicación, obtienes una aplicación más burda, más amplia, más intrusiva y dirigida a todos, porque la versión dirigida ya no se sostiene. Ese es el precio de romper un control básico, y quienes lo rompieron no son quienes lo pagan.

Y a ICANN le da igual, porque desde California no es su problema. Cuando un bloqueo falla o una plataforma incumple sus obligaciones, no es ICANN quien acaba ante un tribunal, es el operador, la plataforma, la empresa, enfrentándose a Ofcom y a las multas. Las consecuencias caen sobre todos los que están aguas abajo de una decisión de la que el organismo que la tomó nunca tiene que responder.

Alinea las consecuencias y todas tienen la misma forma: algo que la red solía aplicar en el resolver, y que ya no puede.

DoT era la respuesta honesta. Cifra tu DNS y deja al operador capaz de hacer su trabajo. DoH conservó el cifrado y añadió una cosa encima: el operador ya no puede verlo. Todo lo demás sobre él se deriva de esa única elección.

Hecho En EE. UU., Litigado En Todo El Mundo

Nada de esto se detiene en el canal de la Mancha, y leerlo como un problema británico lo reduce a una fracción de su tamaño. La misma forma se repite por toda Europa y hasta Australia. Un instrumento legal por un extremo, un bloqueo de DNS en la red por el otro.

En Australia, su Tribunal Federal ordena a los ISP deshabilitar el acceso a sitios infractores en el extranjero al amparo de la section 115A de la Copyright Act²⁰. Portugal se salta el tribunal por completo: un memorando administrativo por el que los titulares de derechos avisan a un organismo llamado MAPINET, y los ISP bloquean por DNS en quince días hábiles²¹. Estatutos distintos, un mismo supuesto que lo sostiene todo, y es el supuesto que DoH les quita de debajo a todos. Que el cliente resuelve a través del resolver que le entregaron.

Así que mira lo que hace un Estado cuando ese supuesto falla. Deja de apoyarse en el ISP y empieza a ordenar a los propios resolvers públicos que devuelvan la respuesta equivocada. No es un pronóstico. Es una pila de sentencias, y no para de crecer.

Léelo como una sola cosa, no como cinco. Un puñado de empresas estadounidenses reescribió el DNS para todo el planeta por su cuenta y riesgo, rompió el control proporcionado que cada uno de estos países había construido, y dejó a los tribunales resolver qué hacer con los restos. Las respuestas que dan esas empresas, arrastradas ante un estrado distinto cada pocos meses, te dicen exactamente cuánto pesa el resto del mundo para ellas. Una recurre y grita censura. Otra falla la consulta y no le dice nada al usuario. Y OpenDNS, el resolver que filtró malware sin ruido durante veinte años y que este artículo ya ha puesto como modelo a copiar, ni siquiera discute. Se apaga para Francia y para Portugal antes que servirles en esos términos²⁶.

Detente en esa última. Es el buen ejemplo de todo este artículo saliendo por la puerta. El servicio que protegía a gente que nunca configuró nada ahora encuentra que abandonar un país entero le sale más fácil que servirlo, y la razón se remonta directamente a una decisión de diseño tomada en California por gente que nunca tuvo que pensar en un tribunal francés ni en uno portugués.

Ese es el patrón, y lo voy a nombrar. Esto es lo que la ingeniería de plataformas estadounidense le hace a todo lo que no sean los Estados Unidos. Construye para su propio mercado, entrega el resultado al mundo como opción por defecto, y trata la ley de cualquier otro país, cada regulador, cada comunidad que queda aguas abajo del cambio, como un lío que ya limpiará otro.

Y el gobierno de casa respalda a las empresas hasta el final. En febrero de 2025 la Casa Blanca puso su firma en un memorando que tacha las leyes digitales de otros países de «extorsión en el extranjero» a las empresas estadounidenses, señalando al Reino Unido y a la UE y apuntando al representante de comercio hacia los aranceles como respuesta²⁷. Seis meses después, un regulador estadounidense escribió a una docena de tecnológicas estadounidenses advirtiendo de que obedecer la Online Safety Act del Reino Unido o la Digital Services Act de la UE podría infringir la propia ley estadounidense²⁸. Léelo dos veces. El país cuyas empresas rompieron los controles ahora les dice a esas empresas que cumplir con la respuesta de otra democracia a esa rotura es el delito.

Eso lo dice todo. Una ley aprobada por un parlamento elegido en Westminster o Bruselas queda recalificada, desde Washington, como un ataque a América, y a las empresas se les dice que la ignoren. No es que sopesaran el resto del mundo y decidieran en contra. El resto del mundo nunca estuvo en la balanza.

La Solución No Es Prohibir El Cifrado

Así que la conclusión perezosa es «bloquear DoH», y es errónea, igual que «bloquear ICMP» es erróneo en el cortafuegos. No quieres el DNS sin cifrar de vuelta. Las consultas en texto claro por el puerto 53 son una exposición real, y volver a ellas para recuperar visibilidad es cambiar un agujero por otro.

Lo que en realidad perdiste no fue el cifrado. Fue la elección del resolver. Así que recupérala y deja el cifrado exactamente donde está.

La forma es la misma que arregla el DNS en un dominio de Active Directory: el argumento nunca es «apagar la característica», es «decidir a quién se le permite conducirla». Esto es lo que significa por partes.

Sirve tú mismo el DNS cifrado. Monta un resolver que sirva DoH y DoT, no solo el puerto 53, para que un cliente que quiera cifrado lo obtenga de ti. No puedes decirles a los clientes «no DoH» y decirlo en serio sin ofrecerles ningún resolver cifrado propio. Dales uno, y mantén la lista de bloqueo, el feed de amenazas y el registro sobre él como antes.

Anúncialo, para que los clientes lo encuentren a propósito. Discovery of Designated Resolvers (RFC 9462) permite a un cliente consultar un nombre especial, conocer el resolver cifrado propio de su red, y pasarse a DoH o DoT contra él automáticamente²⁹. Un cliente consciente de DDR cifra entonces su DNS y usa el tuyo: la privacidad que el usuario quería y el control que tú necesitabas, en un solo movimiento.

Responde al interruptor de apagado del propio navegador. Firefox consulta un dominio canario, use-application-dns.net, antes de activar DoH por defecto: respóndelo con NXDOMAIN o SERVFAIL y Firefox se retira al resolver del sistema³⁰. Dos límites honestos, ambos en palabras de Mozilla. El canario «only applies to users who have DoH enabled as the default option. It does not apply for users who have made the choice to turn on DoH by themselves»³⁰. Así que es una señal de apagado por defecto, no un candado, y no hace nada sobre la app y el malware, que nunca le preguntaron nada al navegador.

Fija la política del navegador donde gestionas la máquina. En un dispositivo que posees, no confíes en el canario. DnsOverHttpsMode de Chrome acepta off, automatic y secure, y la documentación de Google dice que donde no se fija, «for managed devices DNS-over-HTTPS queries will not be sent»³¹; Chrome desactiva su propio DoH automático en cuanto ve una política empresarial¹⁶. Apúntalo a tu resolver, o ponlo en off y deja que DDR lleve el cifrado. Firefox tiene los ajustes equivalentes Enabled, ProviderURL y Locked³². Máquina gestionada, decisión gestionada, y la fila que sí puedes cerrar.

Rechaza las alternativas en la frontera. Las reglas son cortas, y todas dicen lo mismo: DNS de cualquier tipo, hacia el exterior, solo desde tu resolver.

No atraparás cada endpoint DoH por dirección, y no puedes, porque uno nuevo es solo un servidor web y no hay fin de servidores web. Así que asume lo que ese bloqueo cuesta ahora. Para hacer con DoH lo que block 53 outbound hacía gratis, tiras de una lista de direcciones de servidores DoH que otro mantiene escaneando por ti: las listas de bloqueo mantenidas existen porque es la única vía que queda, y una de ellas vuelve a resolver cada dominio DoH público conocido a sus IP actuales cada hora, por tarea programada, y publica los cambios³³. Ese es el trato que forzó la evasión.

Un control que era una línea estática es ahora una suscripción a un blanco móvil, persiguiendo servidores web que cualquiera puede levantar más rápido de lo que una lista puede nombrarlos. Protective DNS cierra el otro extremo: apunta el upstream de tu resolver a un servicio de filtrado como el PDNS del NCSC, que «was built to hamper the use of DNS for malware distribution and operation»³⁴, y los dominios malos se rechazan antes de que se establezca la conexión, para cada cliente que pasa por tu resolver, que, una vez puestas estas reglas, son todos.

Pon eso frente a las cinco filas de antes, y cada una tiene un control que la cierra. Esa es la prueba de una solución: no «¿bloqueamos DoH?», sino «por cada cosa que puede elegir un resolver, qué le impide elegir el equivocado».

Nada de eso apaga un solo bit de cifrado. Los clientes siguen teniendo DoH, solo que lo obtienen de ti, y los que intentan obtenerlo de otro sitio chocan contra un muro. La privacidad queda intacta y el control ha vuelto. Como tal, lo único que alguien perdió es la libertad de elegir un resolver que nunca aprobaste, y esa nunca fue suya en una red de la que eres responsable.

¿Puedo Preguntar Qué Eligió Ese Resolver?

Aquí está la pregunta para ponerle a cualquiera que te diga que la red está bien tal cual.

Cuando una máquina de tu red resuelve un nombre, ¿qué decidió qué resolver respondió? Si la respuesta honesta es «lo que le pasaron al sistema operativo», bien, pero solo si has cerrado las otras cuatro filas de esa tabla, porque si no es «lo que le pasaron al sistema operativo, salvo que el navegador, una app, una página web o algo más feo eligiera otra cosa, en cuyo caso no tengo ni idea y ningún registro». Eso no es una configuración de DNS. Es una esperanza, y con esperanzas no se atrapa nada.

No pregunto quién opera el resolver. Pregunto qué, en cada máquina, puede elegirlo, y si podrías nombrar el resolver al que fue cada consulta ayer. En una red donde DoH no está gestionado no puedes, y la brecha es cada app que lleva su propio resolver, cada página que un usuario abre, y cada pieza de malware que leyó la misma investigación que acabo de enlazar. Tres actores de amenaza con nombre construyeron sus canales sobre esta brecha exacta, y uno responde ante un gobierno.

Un protocolo que le quita a la red la elección del resolver siempre iba a ser un regalo para quienquiera que la red intentara vigilar, y fingir lo contrario porque el marketing decía «privacidad» es como un control que importaba se apaga por defecto y nadie registra el día en que pasó.

Cifra tu DNS. Sirve tú mismo el resolver. Anúncialo, responde al canario, fija la política, cierra la frontera. Conserva el cifrado y conserva la elección. Puedes tener ambos, y si llevas redes para ganarte la vida, tener ambos es el trabajo.

La Privacidad Era La Palabra En La Caja

Así que hay que reconocerlo. Gracias a ICANN, el organismo estadounidense que sostiene la raíz y coescribió esto desde dentro, por ejecutar el manual de la tecnología estadounidense una vez más: coge un problema que ya estaba resuelto, envuelve la solución en una palabra virtuosa, y centraliza el resultado en un puñado de empresas estadounidenses que acaban con el texto claro.

Y siempre es EE. UU. El organismo que sostiene la raíz, el resolver que dos navegadores traen ahora por defecto, la empresa de publicidad que opera el mayor público, el país donde aterriza el texto claro: estadounidense, siempre. Es un patrón, no una racha de mala suerte.

La privacidad era la tapadera. El DNS estaba cifrado, era privado y aún gobernable en el puerto 853 en 2016, y todo el que importaba lo sabía. Lo que el establishment distribuyó encima fue un protocolo construido para cegar a la única persona responsable de la red, una carrera armamentística permanente de listas de bloqueo reescaneadas cada hora, y órdenes judiciales que se estrellan contra el navegador.

Si fue ineptitud o codicia lo dejo a tu criterio, aunque el historial que enlacé apunta en una dirección. En cualquier caso pudo más que el sentido común.

Y decisiones como esta son por lo que las llamadas a quitarle la raíz a ICANN siguen volviendo, y por lo que calan: para que la comunidad internacional tenga voz, en vez de que la institución de un solo país decida el DNS para todos los demás y lo llame custodia.

Todo esto lo hacíamos con una línea.