DNSSEC: proteger tu tráfico contra la falsificación

Cada nombre que tu máquina ha buscado hoy, se lo ha creído. Tu banco, tus actualizaciones, tu servidor de correo. Volvió una respuesta de la red y en ningún punto se comprobó si venía de la organización dueña del nombre o de quien logró colar un paquete antes. Una respuesta DNS corriente no lleva firma, no hay nada que verificar, y no hay nada que fuera a notar que algo va mal. Eso era un diseño razonable en 1983 y dejó de serlo hace mucho tiempo.

DNSSEC es el arreglo para exactamente eso, y no es ni nuevo ni caro. El dueño de la zona firma sus registros. La zona de encima publica un hash de su clave y lo firma, y así hacia arriba, hasta que la cadena llega a una única clave raíz que tu resolver conoce de nacimiento. Cualquier cosa que compruebe la cadena sabe distinguir una respuesta de verdad de una falsificada. Es un estándar desde 2005, la raíz está firmada desde julio de 2010, y las entidades de registro publican los registros sin cobrar nada.^{1 2}

La parte de arriba del árbol está terminada. Conté la zona raíz en vivo para esta entrada y 1.351 de 1.438 dominios de primer nivel están firmados, los 1.038 genéricos entre ellos, todos. Luego se cae por un precipicio. De los 2.390 dominios gov.uk que todavía resuelven, treinta y nueve están firmados, y nueve de esos son juntas parroquiales. El MI6 lo consiguió. El National Cyber Security Centre no.

Esto es lo que cuesta de verdad una respuesta falsificada y lo que hace firmar al respecto, contado sobre la zona raíz en vivo el 27 de septiembre de 2026 y hacia abajo por el gobierno, los bancos, las distribuciones desde las que instalas y las autoridades de certificación. Un comando por dominio, sin pedirle permiso a nadie, y cada nombre listado para que puedas discutir mis elecciones en vez de mi aritmética. Debajo está la pregunta que yo quería responder en realidad. Cuarenta y dos años después de que Mockapetris pusiera el DNS por escrito, ¿la razón de que casi nadie firme es que casi nadie entendió nunca lo que el DNS estaba prometiendo?

Qué es DNSSEC y para qué sirve

En una frase: DNSSEC pone una firma criptográfica en las respuestas DNS, para que un resolver pueda demostrar que una respuesta vino del dueño de la zona y no de quien consiguió responder primero.

No es cifrado, no es un cortafuegos y no es un filtro. Es una firma y una cadena de claves que llega hasta una única clave en la que tu resolver ya confía. Esa es la idea entera.

Ahora el ataque, porque el protocolo solo tiene sentido cuando has visto para qué sirve.

Un resolver que pide un nombre envía una consulta y espera. La respuesta se casa con un puñado de campos: el nombre consultado, el tipo, las direcciones y puertos de origen y destino, y un ID de transacción de 16 bits. Cualquiera capaz de producir un paquete que encaje con esos campos, antes de que llegue la respuesta real, gana. El resolver cachea la falsificación y se la entrega a cada cliente que pregunte, durante todo el tiempo que el atacante haya dicho.

El trabajo de Dan Kaminsky de 2008 es el que todo el mundo recuerda a medias.³ Lo que importa no es que existiera el envenenamiento de caché, porque se sabía de él desde años antes. Es que él encontró la forma de reintentar la adivinanza indefinidamente. Pide un nombre que no existe, y cada intento fallido no cuesta nada y te deja probar otra vez de inmediato, así que el atacante ya no corre una sola carrera contra un registro cacheado que dura un día. La respuesta de la industria fue añadir aleatoriedad: puertos de origen aleatorios encima del ID de transacción aleatorio, lo que llevó la adivinanza de una entre 65.536 a algo cercano a una entre dos mil millones.

Es un número más grande. No es una demostración.

Y la mitigación lleva erosionándose desde entonces, porque cada uno de esos campos es una conjetura que se ha hecho más difícil, no un hecho que se pueda comprobar. La aleatorización de puertos se deshace con un NAT que reescribe puertos de forma predecible. Los ataques por fragmentación se saltan el emparejamiento por completo. Los ataques fuera de camino vuelven una y otra vez con formas nuevas, y cada uno se lleva su propio parche.

Firmar acaba con la discusión. Una respuesta firmada o verifica contra una clave que el resolver puede encadenar hasta la raíz, o no verifica, y por mucho que adivine, un atacante no consigue una firma válida.

Qué les compra de verdad ganar esa carrera

Sé concreto con esto, porque «envenenamiento de caché» suena abstracto y las consecuencias no lo son.

La tercera fila convierte un problema de DNS en un problema de certificados. La emisión validada por dominio funciona pidiéndote que publiques un registro y consultándolo después. Si un atacante puede controlar la respuesta que ve la CA durante esa consulta, la CA le emite papel de verdad a tu nombre, y a partir de ahí el candado del navegador es suyo. Todo lo que se ha enseñado a un usuario a comprobar dirá que el sitio está bien.

La cuarta fila es la callada. Una respuesta falsificada no tiene por qué mandar a nadie a ninguna parte. Basta con apuntar un servicio de actualizaciones a un agujero negro, y no hay nada en la pila construido para gritar por actualizaciones que nunca llegaron.

Qué hace firmar al respecto

El mecanismo es más simple que su fama.

Toda zona firmada guarda un par de claves. El dueño de la zona firma cada conjunto de registros con la mitad privada y publica un RRSIG a su lado. La mitad pública va en la zona como un DNSKEY. Hasta aquí esto no demuestra nada, porque un atacante capaz de falsificar un registro A puede falsificar un DNSKEY a juego.

Lo que lo cierra es el registro DS, y el DS vive en la zona padre, no en la tuya. Es un hash de tu clave, publicado y firmado por la zona de encima. Así que uk responde por tu clave, la raíz responde por uk, y tu resolver nació sabiendo exactamente una cosa: la clave de la raíz.²

Tres tipos de registro hacen el trabajo, y conviene saber cuál es cuál, porque solo uno de ellos es tarea de otra persona:

Puedes publicar los dos primeros por tu cuenta toda la tarde y no cambia nada. Hasta que el padre publique un DS, eres una zona firmada que nadie puede verificar, que es lo mismo que una zona sin firmar con trabajo de más dentro.

$ dig +short @127.0.0.53 uk DS
43876 8 2 A107ED2AC1BD14D924173BC7E827A1...

$ dig +short @127.0.0.53 damiendye.uk DS
2371 13 2 A5B2825C57899A5A15EE9703832C8358E0D19EF29DC72DD83C691ED77C33BD7F

$ dig +short @127.0.0.53 bbc.co.uk DS
                                          (nothing)

Esa del medio es la zona propia de este sitio. uk responde por ella, el algoritmo 13 es ECDSA P-256, y por tanto un resolver validador puede demostrar cada respuesta sobre ella hasta la raíz. bbc.co.uk no devuelve nada, así que no puede.

Un comando te dice si una zona está en la cadena de confianza. Si el padre no publica ningún DS para ti, no estás firmado, tengas configurado lo que tengas, y un resolver validador tratará cada respuesta sobre tu dominio como no verificable.

Ese único registro es la prueba entera.

Lo que no hace

Vale la pena decirlo claro, porque venderlo de más es la mitad de la razón de que la gente desconfíe de ello.

La gente tropieza con esa última fila. DNSSEC demuestra que la respuesta vino de quien controla la zona. No tiene opinión ninguna sobre si esa gente es decente.

Hace exactamente una cosa. Hace que falsificar una respuesta sea aritméticamente inviable en vez de meramente improbable.

Cómo comprobar cualquier zona, incluida la de otro

Esta es la parte que hace posible el resto de la entrada, y se resuelve con un comando.

Una zona está en la cadena de confianza si su padre publica un DS para ella. Esa es la prueba entera, y puedes ejecutarla contra cualquiera, sin permiso, desde cualquier máquina:

dig +short damiendye.uk DS

Que vuelva algo significa firmada. Que no vuelva nada significa sin firmar, tenga la zona lo que tenga configurado.

Si quieres más que un sí o un no, hay tres más que merece la pena conocer:

Dos trampas que conocer antes de fiarte de tus propios resultados, porque las dos me pillaron mientras medía para esta entrada.

dig +short … DS imprimirá una cadena de CNAME si el nombre es un alias, y un nombre de host con dígitos se parece lo bastante a un registro DS como para engañar a un script ingenuo. Un DS de verdad son cuatro campos: etiqueta de clave, algoritmo, tipo de resumen y resumen en hexadecimal. Casa esa forma, o contarás como firmadas zonas que no lo están.

Un DS bajo un padre sin firmar no significa nada. La cadena tiene que llegar a la raíz. update.microsoft.com tiene un DS, y microsoft.com no, así que la rama es no verificable igualmente. Comprueba siempre el camino entero, no un nivel.

Todo lo que se cuenta en el resto de esta entrada se midió así. Sin escáner, sin panel de terceros, sin la tabla clasificatoria de ningún fabricante. Pregúntale al padre si responde por el hijo, e insiste en que la respuesta parsee como un DS.

La zona raíz está terminada

Aquí es donde la sabiduría recibida está sencillamente desfasada. La gente todavía habla de DNSSEC como si el problema fuera la infraestructura.

Descargué la zona raíz en vivo el 27 de septiembre de 2026, serial 2026092701, y conté las delegaciones contra los registros DS.⁴

Todos y cada uno de los dominios genéricos de primer nivel están firmados. Los 1.038, sin excepciones, porque el Registry Agreement de la ICANN lo exige a cualquier cosa delegada bajo el programa de nuevos gTLD. Los 87 que no están firmados son casi todos códigos de país, y la lista es sobre todo territorios pequeños y un puñado de estados:

ae ao aq ba bb bo bs cd cf cg ck cu cv cw do eg fk gb gf gh gm gp gq gt gu
hm im iq jm jo kh km kn kp mh mk mo mp mq mt mv mw mz ne ni np nr om pa pf
pk pn ps qa sd sl sm so st sv sy sz td tg tj tk to va vg vi ye zw

gb está ahí dentro, lo que es una curiosidad más que un problema, ya que nadie lo usa para nada. También están el Vaticano, Corea del Norte, Cuba y Siria. Y tk, que durante años fue la mayor fuente de dominios gratuitos de internet y, con ellos, una fuente fiable de abusos.

Así que la parte de arriba del árbol está hecha. Las entidades de registro hicieron la parte difícil, la parte cara y la parte que necesitaba coordinación internacional, y la terminaron. Por tanto, nada por debajo de este punto se le puede echar a la infraestructura.

Y entonces se para en seco

Por debajo del TLD, el cuadro se invierte del todo.

Medí de la misma forma para cada conjunto de abajo: pedirle al padre un DS, aceptar solo un registro que parsee de verdad como tal. Todo lo de aquí se contó el 27 de septiembre de 2026.

Noventa y cuatro por ciento arriba. Uno y medio por ciento abajo. La cadena de confianza es una cadena con un extremo atornillado a la pared y el otro tirado en el suelo.

Una nota sobre el método, porque un número tan malo la merece. La fila de gov.uk es un censo y no una muestra: son todos los dominios de segundo nivel del registro que publica el propio gobierno, filtrados a los 2.390 que todavía resuelven. Las demás filas son listas curadas de las organizaciones cuya falsificación haría daño de verdad, lo cual es un juicio personal, y he listado todos los nombres más abajo para que puedas discutir mis elecciones en vez de mi aritmética.

El censo del gobierno: 39 de 2.390

La lista oficial de dominios gov.uk que publica el gobierno llega a 3.004 nombres de segundo nivel. De esos, 2.390 todavía resuelven. Treinta y nueve están firmados.

Antes del detalle, una cosa sobre ese registro. La versión más reciente que publica gov.uk lleva fecha del 1 de octubre de 2016.⁵ Una década, para la lista autoritativa de los dominios en los que responde el Estado británico. Eso es un pequeño hallazgo de por sí y lo dejo ahí.

Ahora mira cuáles son esos treinta y nueve.

Lee otra vez esa primera columna. El Servicio Secreto de Inteligencia ha firmado su zona. El National Cyber Security Centre no.

Tampoco el GCHQ, que es la organización matriz del propio NCSC. Tampoco el esquema Cyber Essentials, que existe para certificar que la seguridad de otra gente es adecuada. No voy a fingir que eso sea otra cosa que notable.

Y nueve de los treinta y nueve son juntas parroquiales y municipales. Abinger. Aldenham. Ashmansworth. Wheathampstead. Frampton on Severn. Sitios con un secretario, una web a tiempo parcial y un presupuesto que no cubriría un día de consultoría en Whitehall. Ellos lo consiguieron. HMRC, que guarda el expediente fiscal de todos los adultos del país, no.

¿Puedo preguntar qué hay en el proceso que permite eso? No quién: qué. Porque el NCSC publica guías que le dicen a otros que desplieguen DNSSEC, y el departamento que escribe la guía no ha hecho lo que la guía dice. O es importante, en cuyo caso el organismo que lo afirma debería haberlo hecho hace años, o no lo es, en cuyo caso la guía debería decir eso en su lugar.

La excusa que se ofrecerá será la escala y el legado. No sobrevive a la primera columna. somerset.gov.uk es una autoridad unitaria que atiende a 580.000 personas y está firmado. birmingham.gov.uk es una autoridad unitaria que atiende a 1,1 millones y no lo está. Mismo país, mismo registro, mismos registradores, mismo dinero disponible para los mismos proveedores. Uno lo hizo.

El software desde el que te actualizas

Esta es la parte que debería preocuparte más que los bancos, y es la parte que casi nadie mide.

Cada máquina que ejecutas descarga código de algún sitio con una periodicidad, y encuentra ese sitio preguntándole al DNS.

Noventa y nueve distribuciones y BSD, noventa y seis de ellas todavía resolviendo. Diecinueve están firmadas.

Diecinueve de noventa y seis. Y los nombres de esa lista sin firmar no son oscuros: Ubuntu, Red Hat, SUSE, Oracle, Arch, Alpine, NixOS, Rocky, todos los sabores de Ubuntu, y tanto kernel.org como gnu.org.

Las distribuciones de seguridad y privacidad son las que yo esperaba que fueran distintas, y en su mayoría no lo son. Tails y Whonix han firmado, lo que encaja. Kali, Parrot, Qubes, Trisquel y PureOS no, lo que no encaja. OpenBSD lleva veinticinco años construyendo una reputación sobre acertar precisamente en esta clase de cosas y no ha firmado openbsd.org, mientras que FreeBSD, NetBSD, HardenedBSD y MidnightBSD lo han hecho todas.

Los registros de paquetes están cerca de un pleno en la columna equivocada: npm, crates.io, RubyGems, Packagist, Docker Hub y Quay están todos sin firmar. pypi.org es la excepción, y hay que reconocérselo, porque además es de los más atacados.

Microsoft y el canal de actualizaciones

Cuatro de veintiséis zonas de Microsoft están firmadas, y son todas un rincón del parque:

Los nombres de Outlook y Office están firmados y nada más lo está, lo que parece la decisión de un equipo y no de una empresa. Fíjate en qué hay en la columna de la derecha junto al servicio de actualizaciones: github.com y npmjs.com, dos de los mayores puntos de distribución de código de internet, ambos propiedad de Microsoft, ambos sin firmar.

$ dig +short @127.0.0.53 windowsupdate.com DS
                                          (nothing)
$ dig +short @127.0.0.53 microsoft.com DS
                                          (nothing)
$ dig +short @127.0.0.53 com DS
19718 13 2 8ACBB0CD28F41250A80A491389424...

com está firmado, así que no hay nada técnico en medio. Microsoft podría publicar un DS esta misma tarde.

La respuesta de manual a por qué eso da igual es que el DNS es solo una capa. Las cargas de actualización van firmadas por código, el cliente comprueba la firma, y el tráfico va sobre TLS. Rompe el DNS y sigues sin poder hacer que se ejecute código.

Esa respuesta depende por entero de que la firma sea sólida. No lo ha sido.

Sé preciso con esa última fila, porque la gente la exagera. La clave robada firmaba tokens de identidad, no binarios. Está en la tabla por otra razón: la custodia del material de firma de Microsoft falló, sin detectarse durante dos años, por un volcado de memoria y una cuenta de ingeniero comprometida.

Las filas de encima son los fallos de firma de código, y son peores. Dos veces en un año, el propio programa de certificación de hardware de Microsoft le puso una firma de Microsoft a un rootkit funcional y lo distribuyó. Ni un certificado falsificado, ni una clave robada. El proceso legítimo, firmando malware, exactamente como está diseñado.

Así que la defensa que te permite tratar el DNS como opcional ha sido subvertida por falsificación, por abuso de proceso y por robo de claves, a lo largo de once años. Un atacante con una firma que la máquina va a aceptar no es un experimento mental. Para un actor respaldado por un Estado es un problema de compras, no de investigación.

Dale a ese atacante una respuesta DNS falsificada y el cuadro queda completo: código firmado que él controla, entregado desde un servidor que la máquina cree que es de Microsoft, sobre una conexión que nada en la pila va a cuestionar. Eso es Flame, con mejor material de claves.

DNSSEC es la única capa de esa cadena a la que le da igual qué clave de firma tenga el atacante. No valida la carga, valida adónde se mandó a la máquina, y falla de forma independiente de cada certificado y cada firma en juego. Que es precisamente lo que quieres de una segunda capa, y precisamente por qué no debería ser la que está apagada.

Y hay un ataque más barato que no necesita clave ninguna. Falsifica la respuesta para que el servicio de actualizaciones resuelva a ninguna parte útil, y la máquina sencillamente no se parchea nunca. Ningún error sobre el que el usuario vaya a actuar, ninguna alarma, solo un parque quedándose atrás en silencio mientras el panel dice que todo va bien. Si yo quisiera un parque listo para explotar dentro de seis meses, no le enviaría nada. Solo me aseguraría de que no le llegase nada.

Los bancos, al completo

Esta vez no es una muestra. Noventa y ocho bancos y sociedades hipotecarias del Reino Unido, todos resolviendo ese día, desde la banca de la calle principal hasta sociedades con una sucursal y un nombre victoriano.

Trece están firmados.

Treinta y ocho sociedades hipotecarias. Ni una firmada. Esas son las instituciones que tienen la hipoteca de muchísimas casas.

Dos patrones destacan en esa columna de firmados. Lloyds Banking Group ha firmado tres de sus marcas, lloydsbank.com, halifax.co.uk y bankofscotland.co.uk, y el Co-operative Bank ha firmado las dos suyas. Así que la decisión se toma una vez, a nivel de organización, y luego se aplica. No hay ningún obstáculo por dominio.

Y Monzo ha firmado mientras Starling no. Dos bancos retadores fundados con un año de diferencia, sobre infraestructura moderna comparable, con el mismo regulador y los mismos registradores disponibles. Uno lo hizo.

El único sitio donde lo hace todo el mundo

Mira los dos últimos nombres de la columna de firmados: allica.bank y weatherbys.bank.

.bank es un dominio de primer nivel restringido que lleva fTLD Registry Services, y sus requisitos de seguridad hacen DNSSEC obligatorio, junto a TLS y autenticación de correo, con reverificación anual de cada registrante.⁹

Dos es un número pequeño, así que tómalo como una demostración y no como una estadística. El requisito sigue siendo lo único que cambió.

Esa es la respuesta a cada excusa que viene más abajo en esta entrada, y llega antes que las excusas. Los mismos bancos, los mismos proveedores, los mismos presupuestos y las mismas habilidades producen un 13 % de cumplimiento cuando es opcional y un 100 % cuando alguien comprueba cada año. Nada técnico se movió. Simplemente alguien preguntó.

Nadie está vigilando a los vigilantes

Una autoridad de certificación de cada nueve.

Estas son las organizaciones cuyo negocio entero es demostrar que algo es lo que dice ser. También son las organizaciones que validan el control de un dominio por DNS, pidiéndote que publiques un registro y consultándolo después. La consulta que decide si consigues un certificado para un dominio es, en ocho de estas nueve, una consulta que nadie puede verificar.

Nada hipotético, eso. Es la forma documentada: falsifica la consulta de validación, consigue que te emitan el certificado, y ya tienes papel válido para un nombre que no es tuyo. DNSSEC es una de las pocas cosas que hacen eso materialmente más difícil, y la gente a la que más protegería no lo ha desplegado.

Y esto te lo digo gratis. Si tu modelo de negocio es la identidad, y no has firmado tu propia zona, el argumento de que es difícil no está a tu disposición.

¿Y quién está comprobando de verdad?

Firmar es solo la mitad. Una zona firmada no protege a nadie si no hay algo al otro extremo que verifique la firma, y aquí el cuadro empeora en vez de mejorar.

Hay dos sitios donde puede ocurrir la validación, y no son equivalentes:

Casi toda la validación del mundo es de la primera clase. Google, Cloudflare y Quad9 validan todos, y entre ellos cubren un número enorme de usuarios. Eso cuenta para algo. Pero significa que la propiedad que tiene la mayoría es mi resolver dice que esto estaba bien.

Qué puede hacer cada sistema operativo

Dos de esos merecen más que una fila.

Apple hizo el trabajo sin ruido. iOS 16 y macOS Ventura añadieron validación DNSSEC del lado del cliente, en palabras de la propia Apple en la WWDC 2022: «iOS 16 and macOS Ventura now support client side DNSSEC validation», validación DNSSEC en el propio cliente.¹⁰ Es opcional en vez de automática, y es opcional con la granularidad correcta, así que una aplicación a la que le importe puede pedirla por sesión o por petición:

let configuration = URLSessionConfiguration.default
configuration.requiresDNSSECValidation = true

Un resolver validador de verdad en un teléfono, comprobando firmas en el dispositivo, y casi nadie se dio cuenta de que llegaba. Antes de eso, mDNSResponder exponía kDNSServiceFlagsValidate para quien quisiera usar la API de C.

Android no lo ofrece. El resolver de DNS es un módulo actualizable desde Android 10 y ganó DNS sobre TLS en Android 9, así que la plataforma no ha estado parada en materia de DNS. Pero ni la documentación del resolver de AOSP ni la API pública DnsResolver documentan validación DNSSEC, y la razón de que existan bibliotecas como MiniDNS y anuncien que acercan «DNSSEC close to your application» es que la plataforma no lo trae. No pude encontrar una fuente primaria que dijera sin rodeos que es imposible, así que no lo pondré más alto que esto: no se ofrece, y lo estarías escribiendo tú.

Y se tira incluso donde funciona

Una cosa más, de esta máquina, que no esperaba encontrar.

El resolver de upstream de aquí valida y lo dice. systemd-resolved, con DNSSEC=no, tira eso a la basura antes de que lo vea ninguna aplicación:

# ---- before: stock Fedora, DNSSEC=no ----------------------------------
$ dig @192.0.2.53  damiendye.uk A | grep flags      # the upstream
;; flags: qr rd ra ad

$ dig @127.0.0.53  damiendye.uk A | grep flags      # the local stub
;; flags: qr rd ra

# ---- the fix: two lines in a drop-in ----------------------------------
$ sudo mkdir -p /etc/systemd/resolved.conf.d
$ printf '[Resolve]\nDNSSEC=allow-downgrade\n' \
    | sudo tee /etc/systemd/resolved.conf.d/10-dnssec.conf
$ sudo systemctl restart systemd-resolved

# ---- after: same query, same stub, nothing else changed ---------------
$ resolvectl status | grep -m1 DNSSEC=
                    DNSSEC=allow-downgrade/supported

$ dig @127.0.0.53  damiendye.uk A | grep flags
;; flags: qr rd ra ad

Mismo nombre, misma respuesta, mismo segundo. Antes del drop-in el upstream hacía el trabajo, ponía el bit AD, y el demonio local lo dejaba caer al suelo, así que el valor por defecto no es simplemente aquí no validamos, es aquí no validamos, y tampoco vamos a pasarte el veredicto de nadie que sí lo haya hecho. Después, el bit ha vuelto y esta vez es nuestro en vez de la afirmación de otro.

resolvectl pone el veredicto en palabras, y separa los dos que importan:

$ resolvectl query damiendye.uk | tail -2
-- Data is authenticated: yes; Data was acquired via local or encrypted transport: no

$ resolvectl query ncsc.gov.uk | tail -2
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no

Fíjate en lo que no es la segunda. No es un error. Una zona sin firmar vuelve como no autenticada en vez de como bogus, la resolución tiene éxito, y no se queja nadie en ninguna parte. Ese es el problema entero del 1,63 % dicho como un comando: activar la validación no hace que las zonas sin firmar fallen, las hace visibles, y solo para quien vaya a mirar.

El sistema operativo cliente más grande falla la comprobación más básica

Ahora el otro extremo de la escala, y no está ni cerca.

El cliente DNS de Windows es, en descripción de la propia Microsoft, «security-aware» pero «non-validating»: consciente de la seguridad, pero sin validar nada. No realiza validación DNSSEC. No se le puede hacer realizarla. Lo que hace en su lugar es pedirle a su servidor DNS configurado que valide, y luego buscar el bit AD en la respuesta.¹¹

Tres cosas sobre eso, y ninguna es pequeña:

• Nunca comprueba una firma. La garantía más fuerte disponible para el mayor sistema operativo cliente del mundo es un único bit puesto por la máquina que respondiera.
• Ni siquiera hace eso por defecto. El cliente solo pone el bit DO y exige AD para los espacios de nombres listados en la Name Resolution Policy Table, un objeto de directiva de grupo que alguien tiene que configurar a propósito. Sin ninguna regla dentro, la consulta no lleva expectativa DNSSEC ninguna.
• Microsoft dice que el bit necesita IPsec para significar algo. Su documentación es explícita en que, como el cliente no valida y se apoya en el servidor, «IPsec is used to establish this trust relationship», se usa IPsec para establecer esa relación de confianza. Un bit AD que llega por un enlace no autenticado es una afirmación de quien llegó primero, que es exactamente el ataque para el que existe toda esta tecnología.

Así que en el escritorio con la mayor base instalada, tal cual sale de la caja: sin validación, sin exigencia de AD y sin canal autenticado hacia el resolver. La comprobación más básica no está meramente apagada. Nunca se implementó.

Y la defensa habitual, la de que los sistemas operativos cliente sencillamente no hacen esta clase de cosas, se murió en 2022. Apple llevó la validación en el dispositivo a cada iPhone y cada Mac el mismo año en que Microsoft no lo hizo. La comparación ya no es escritorio contra servidor, ni móvil contra fijo. Es un fabricante que lo construyó contra otro que no.

Eso importa más que la misma carencia en Linux, por a quién afecta. Un servidor Linux lo lleva normalmente alguien que podría activar la validación esta tarde y sabe lo que es un registro DS. Las máquinas que no pueden validar en absoluto, con ningún ajuste, son las que están sentadas en las mesas de las organizaciones cuyas zonas salen sin firmar en las tablas de arriba. systemd-resolved trae la capacidad apagada, que es una decisión que puedes revertir en una línea.¹² El Fisher-Price OS (Windows) se entrega sin la capacidad.

El servicio que se sostiene con DNS

Todo lo anterior han sido nombres en la internet pública. El mismo agujero existe dentro del edificio, y ahí dentro aguanta carga.

Active Directory no tiene dirección fija para nada. Una máquina unida al dominio no sabe dónde vive su controlador de dominio, así que le pregunta al DNS. El proceso localizador consulta _ldap._tcp.dc._msdcs.<domain> para los controladores y _kerberos._tcp para el KDC, y contra lo que vuelva es contra lo que va a autenticarse.¹³

dig +short _ldap._tcp.dc._msdcs.corp.example SRV

Falsifica esa respuesta y la máquina lleva su tráfico de autenticación a un host que elegiste tú. Sé claro con lo que eso es y lo que no: Kerberos no le va a dar un ticket a un impostor que no tenga las claves, así que esto no es una toma del dominio por sí solo. Es una posición en el camino, que es de lo que están hechos los ataques interesantes. Fuerza la caída a NTLM y retransmítelo. Siéntate en medio del tráfico que iba a ir a un controlador. O apunta el parque entero a ninguna parte y mira cómo se paran los inicios de sesión.

Las directivas de grupo, los scripts de inicio de sesión, las unidades de red y todas las confianzas aguas abajo del inicio de sesión se encuentran igual. Es el conjunto de nombres de más valor que tienen la mayoría de las organizaciones, y está ahí sentado sin firmar.

Microsoft construyó la mitad servidora del arreglo, y la construyó bien. Una zona integrada en AD se puede firmar, la firma en línea de zonas dinámicas llegó en Windows Server 2012, y como la zona vive en el directorio, las claves de firma privadas se replican a los demás servidores DNS por la propia replicación de AD.¹⁴ La parte genuinamente incómoda de DNSSEC, llevar las claves a las máquinas que las necesitan, se resolvió aquí hace catorce años con lo mismo por lo que la zona ya se replicaba.

Luego se para en los mismos dos sitios que todo lo demás:

Así que la zona interna que decide qué máquina va a ser tu controlador de dominio está, en la mayoría de los parques, tan sin firmar como la pública. La diferencia es que ningún extraño puede contarla, así que no hay tabla en esta entrada avergonzando a nadie. Ve a mirar la tuya antes de dar nada por hecho.

Esto debería hacerlo el sistema operativo, y debería venir encendido

Lo que me lleva a la parte de esto que quiero argumentar en vez de contar.

Validar una respuesta DNS es trabajo del sistema operativo. Está en la misma clase de tarea que mantener el reloj en hora, llevar un almacén de certificados de confianza y tener una pila TLS, y por las mismas razones: toda aplicación lo necesita, casi ninguna debería estar escribiéndolo, y la comprobación tiene que ocurrir una vez, en un sitio donde se pueda hacer bien. Esa discusión la zanjamos para los certificados hace mucho. Nadie entrega un cliente de correo con su propia opinión privada sobre las CA raíz.

Tres de las cuatro plataformas de arriba ya pueden hacerlo. Ninguna lo hace de serie:

$ grep DNSSEC= /usr/lib/systemd/resolved.conf   # Fedora 44, systemd 259.9
#DNSSEC=no

Ese es el valor por defecto compilado, escrito comentado para que un administrador pueda ver cuál es. El propio manual de systemd tiene otra opinión, y recomienda allow-downgrade en general y true allá donde se pueda confiar en el upstream.¹⁵ El código se entrega, el ancla de confianza de la raíz se entrega, y la documentación se entrega recomendando que lo actives. El valor por defecto sigue diciendo que no.

Esa columna es el problema entero. Un requisito es una palanca, y la cuenta de .bank de más arriba enseña lo que hace. Un valor por defecto es la misma palanca sin que nadie tenga que hacer cumplir nada, porque decide el resultado para todo el que nunca abre el fichero de configuración, que es casi todo el mundo. Lo opcional nos dio un 1,63 % en el gobierno y un 13 % en la banca. La gente no se apunta a una seguridad que no ve, y tener razón sobre la tecnología no ha cambiado eso ni una sola vez.

La objeción honesta es que validar por defecto rompe a los usuarios cuando lo roto es el resolver de upstream y no la zona. Para eso está allow-downgrade, y es un compromiso de verdad y no uno gratis, porque una degradación es algo que un atacante puede provocar a propósito. Aun así, entregar allow-downgrade en vez de un no a secas sería una mejora enorme, y pondría la rotura donde le toca, sobre quien siga llevando en 2026 un resolver incapaz de manejar DNSSEC.

Activar la validación, y qué parte es de Fedora

Casi todo lo que sigue es de systemd y no de Fedora, y funciona igual en Debian, Ubuntu o Arch. Dos cosas de aquí sí son genuinamente de la distribución:

Upstream elige allow-downgrade en meson_options.txt, que es el ajuste de compromiso, no el valiente.¹⁶ Fedora lo compila a no y luego entrega un segundo fichero principal de configuración, y como solo se usa el primer fichero encontrado, el que documenta los valores por defecto ya no es el que está en vigor.¹⁵ Así que no edites ninguno de los dos. La copia del fabricante es del paquete y una actualización te devolverá tu cambio a la cara; la copia de /etc es un fichero cuyas demás líneas están calladamente ausentes.

Usa un drop-in en su lugar, que es lo que hace el bloque de más arriba. Sobrescribe al fichero principal que haya ganado, sobrevive a las actualizaciones de paquetes y contiene solo lo que cambiaste. Comprueba el resultado con systemd-analyze cat-config systemd/resolved.conf, que imprime cada fichero en el orden en que se aplica y zanja qué ganó de verdad.

Tres ajustes, y la elección entre los dos últimos es real:

Empieza en allow-downgrade, porque así un resolver roto no te cuesta nada. Pasa a yes cuando resolvectl status lleve quince días diciendo supported y sepas qué es tu upstream en realidad. El detalle por distribución para todo lo que no sea Fedora está en la entrada sobre resolved.¹²

Entonces, ¿qué está frenando a la gente de verdad?

Bien. Los números son los números. ¿Por qué?

Se dan cuatro razones, y no todas son basura.

La gestión de claves fue un obstáculo genuino y en su mayoría ya no lo es. Firmar solía significar llevar tus propias ceremonias de claves, acordarte de volver a firmar antes de que caducaran las firmas, y rotar claves a mano con un calendario que tenías que seguir tú. Ese trabajo lo hace hoy el proveedor de DNS en la mayoría de las plataformas gestionadas, y firmar es un interruptor. No es gratis, pero ya no es un proyecto.

El modo de fallo es la objeción honesta, y es la única de las cuatro con la que tengo simpatía de verdad. Haz mal DNSSEC y tu dominio no se degrada, desaparece. Cada resolver validador rechaza tus registros, que es lo que se supone que debe hacer, y a la gente que no puede alcanzarte no puedes decirle por qué, porque decírselo requiere DNS.

Tres cosas lo hacen peor que una caída corriente:

• Falla por reloj, no por un cambio. Las firmas llevan caducidad. Una zona que nadie ha tocado desde el martes puede haber desaparecido el domingo porque un trabajo de refirmado dejó de ejecutarse en silencio.
• Falla para unos y no para otros. Solo te rechazan los resolvers validadores. Tu propia monitorización, si no valida, informará de que el sitio está perfectamente sano mientras una fracción creciente de internet no puede alcanzarte.
• Falla en la capa que usas para arreglar cosas. El acceso remoto, tu página de estado y tu propio correo pueden estar todos bajo el nombre que acaba de desaparecer.

Ese miedo es racional, ha dejado fuera de antena a operadores grandes, y cualquier defensa honesta de DNSSEC tiene que convivir con él en vez de espantarlo con la mano.

Pero fíjate en su forma: es miedo a una disciplina operativa que no tienes ahora mismo, no miedo a la tecnología.

Y fíjate en quién paga en cada columna. Una zona sin firmar que sufre una falsificación les cuesta a tus clientes, en silencio, y nadie abre nunca un incidente porque nadie se entera nunca. Una zona firmada que caduca te cuesta a ti, de inmediato, en público, con tu nombre en el postmortem. Los dos son fallos. Solo uno de ellos aparece en los objetivos de alguien.

Los certificados tuvieron el mismo problema y lo resolvieron por partida doble: se hizo visible el fallo, y luego se automatizó. Un aviso del navegador convirtió un certificado caducado en problema de todos, la monitorización vino detrás, y luego Let’s Encrypt convirtió la renovación en algo que hace un cron a las tres de la mañana. Nada de eso hizo los certificados más fáciles en principio. Hizo más difícil olvidarlos.

El soporte del proveedor merece diez minutos de comprobación en vez de darlo por supuesto. Algunos registradores todavía hacen que publicar un DS sea un ticket de soporte. Muchos no.

Y la última es la respuesta de verdad, que el registro .bank ya demostró más arriba en esta entrada. No hay candado de navegador para DNSSEC. Ningún cliente ha elegido jamás un banco porque su zona estuviera firmada, ningún auditor te suspende por ello, y ninguna normativa general del Reino Unido lo exige. El beneficio es completamente invisible cuando funciona, el coste de equivocarse es una caída con tu nombre encima, y quien carga con esa caída no es quien se llevaría el mérito.

Ponles un requisito y una comprobación anual delante a esas mismas instituciones y el cumplimiento pasa del 13 % a todas y cada una. Nada de la tecnología cambió entre esos dos números. Nada de los presupuestos, los proveedores o las habilidades cambió tampoco. La única variable fue si alguien iba a mirar.

Con esos incentivos, lo sorprendente no es que esté firmado el 1,63 % de los dominios del gobierno. Es que lo estén treinta y nueve.

Activarlo sin quedarte fuera de antena

Todo el riesgo está en un solo sitio, así que pon el esfuerzo ahí. La caducidad de las firmas es el fallo que llega sin que nadie haya tocado nada, así que ponle alarma:

dig +dnssec damiendye.uk SOA | awk '/RRSIG/ {print "sig expires", $9}'

Trátalo como un certificado. Vigila la fecha, alarma bastante antes, y haz que la renovación sea automática para que la alarma sea una red de seguridad y no un flujo de trabajo.

Luego actívalo en un momento tranquilo, sobre algo que no sea tu dominio principal, y déjalo quince días antes de hacer el que importa. Si tu DNS está en una plataforma gestionada, la firma en sí es muy probablemente un interruptor, y el único paso genuinamente manual es depositar el DS en tu registrador.

¿Es este el mismo fracaso que el de IPv6?

Es la comparación obvia, así que medí los dos estándares en las mismas poblaciones el mismo día. Las mismas organizaciones, la misma gente, dos decisiones.

Diecinueve veces más avanzado en el gobierno, sobre los mismos dominios.

Ahora párate en cuál es cuál. IPv6 toca cada router, cada host y cada aplicación, y quiere doble pila corriendo en paralelo durante años. Firmar con DNSSEC es un interruptor y un registro pegado en tu registrador.

El trabajo mucho más difícil le está ganando al fácil en todas partes donde miré. Lo que descarta la explicación cómoda de que así es como van los estándares de infraestructura, despacio y a regañadientes. DNSSEC no se mueve despacio. No se mueve.

Una diferencia le pertenece solo a DNSSEC. Despliega IPv6 y recibes algo: alcanzabilidad, ningún NAT de operador que comprar. Firma tu zona y tú personalmente no recibes nada. La protección cae sobre tus usuarios, y solo sobre los que están detrás de un resolver validador. Asumes un riesgo permanente de caída en nombre de gente a la que nunca conocerás, y eso es más difícil de poner delante de un consejo que cualquier obstáculo técnico de esta entrada.

He escrito la mitad de IPv6 de este argumento en otro sitio y no la voy a repetir aquí.¹⁷

¿Será que seguimos sin entender el DNS?

Cuarenta y dos años desde que Mockapetris lo puso por escrito en noviembre de 1983.¹⁸ Dieciséis desde que se firmó la raíz.

Creo que el problema de comprensión es real, y creo que es más específico que el de que la gente no sepa cómo funciona el DNS. Muchos ingenieros competentes saben describir la recursión, la delegación y el cacheo perfectamente. Lo que falta es un paso más allá, y es el paso que importa.

Casi nadie ha interiorizado que el DNS es un sistema de autorización.

Se le trata como fontanería. Una tabla de consulta. Algo que convierte nombres en números y pertenece a quien lleve la red, archivado mentalmente al lado del DHCP. Y ese marco está mal de una manera que decide calladamente muchísimo, porque en la práctica la respuesta DNS es lo que decide a qué máquina va tu tráfico, de qué servidor vienen tus actualizaciones, y qué host cree una autoridad de certificación que es el tuyo. Quien controla la respuesta controla las tres cosas.

Se ve el malentendido en el patrón de quién ha firmado. Ni presupuesto, ni habilidad tampoco, y cuando lo alineas cuesta leerlo como otra cosa que un patrón de lo que cada uno cree que es el DNS:

La gente más cercana al DNS como cosa en sí ha firmado toda. La gente que lo consume como un suministro no, casi sin excepción, por bien dotada de recursos que esté y por muy consciente de la seguridad que se crea. El GCHQ no ha firmado. Ocho de nueve autoridades de certificación no han firmado. Estas no son organizaciones escasas de gente lista ni de modelos de amenaza.

Por eso también la respuesta de 2008 a Kaminsky fue hacer la adivinanza más difícil en vez de terminar de desplegar la cosa que hace irrelevante adivinar. Hacer la adivinanza más difícil es un arreglo de fontanería, y la fontanería es donde la industria tenía archivado el DNS.

Una generación aprendió el DNS como un directorio, y nunca revisó la entrada cuando calladamente se convirtió en lo que decide con quién estás hablando.

Lo construimos y luego lo dejamos ahí

Las entidades de registro, los operadores y la gente de los estándares hicieron la parte difícil. Lo escribieron, lo discutieron en el IETF durante una década, firmaron la raíz en una ceremonia con testigos, y consiguieron que estuviera firmado el 100 % de los dominios genéricos de primer nivel. Eso es una pieza genuina de ingeniería colectiva y está terminada.

Y luego los demás no hicimos nuestra parte, porque nuestra parte es aburrida, invisible, carga con todo el perjuicio personal y con nada del mérito, y no la comprueba nadie.

Esa es la forma de todo estándar que nadie hace cumplir: el coste se carga en solitario, y el beneficio solo aparece cuando lo han cargado bastantes más. Así que las entidades de registro lo cargaron, y la gente que publica la guía sobre cargarlo no.

Salvo que el trabajo aquí era más pequeño que casi ninguno de ellos. La cadena ya estaba construida, y pagada, por otro. Lo único que quedaba era un registro.

Y si esta es la parte que podemos ver

Un último pensamiento, y quiero dejar claro que es una inferencia y no una medición, porque todo lo demás en esta entrada está contado y esto no.

DNSSEC es más o menos el control de seguridad más fácil de evaluar que existe. No cuesta nada, el trabajo es una tarde, el estándar lleva veinte años terminado, y cualquiera puede comprobarlo desde fuera con un comando sin pedir permiso. Sin auditoría, sin cuestionario, sin acuerdo de confidencialidad. Un dig.

Entonces, ¿qué te dice un 1,6 % sobre los controles que no se pueden ver desde aquí fuera?

Cada fila por debajo de la primera es más difícil que firmar una zona, cuesta dinero de verdad, necesita que alguien la haga suya, y comparte la propiedad exacta que hundió a DNSSEC: invisible cuando funciona, y nadie de fuera comprobándola. Lo único que separa la fila de arriba del resto es que puedes comprobarla, gratis, sobre cualquiera, ahora mismo.

Si una organización no ha hecho la cosa gratis que lleva una tarde y que un desconocido puede verificar con un comando, no me inclino a suponer que haya hecho las cosas caras que llevan un programa entero y que solo puede verificar alguien a quien dejen entrar.

Ahora, el movimiento obvio es contrastar eso con el historial de brechas, y lo intenté. De 23 organizaciones del Reino Unido con incidentes graves documentados, 22 están sin firmar.

Ese número no demuestra nada y no voy a fingir lo contrario. Con una tasa base del 1,6 %, una organización firmada en una lista de 23 es exactamente lo que predice el azar. Peor todavía, el conjunto firmado son nueve juntas parroquiales y tres parques nacionales mientras que el conjunto sin firmar son todos los ministerios grandes y todas las ciudades grandes, así que el tamaño manda tanto sobre a quién atacan como sobre quién acaba en las noticias. Cualquier comparación de tasas de brecha entre los dos grupos estaría midiendo lo grande que es una organización, no si firmó.

Así que no, no puedo enseñarte que las organizaciones firmadas sufran menos brechas. No puede nadie, no con datos que cualquiera pueda conseguir, y quien te diga otra cosa te está tomando el pelo.

Las organizaciones a las que les dieron escribieron qué falló

No necesitas mi inferencia, porque lo publicaron ellas mismas, y lo que falló es la lista de arriba.

La British Library es la mejor de todas, porque lo escribió voluntariamente y con detalle tras su ataque de ransomware de 2023. Su propia revisión nombra las causas: entrada muy probablemente por una cuenta de terceros en un servidor de Terminal Services sin autenticación multifactor, luego infraestructura heredada y segmentación de red limitada que dejaron a los atacantes moverse por el parque, con la creciente complejidad del acceso de terceros señalada internamente como riesgo en 2022 y todavía ahí un año después.¹⁹ La ICO llegó a las mismas conclusiones.²⁰

Tres filas de la tabla de arriba, entonces, confirmadas desde dentro por la propia organización en vez de inferidas por mí desde aquí fuera.

Y antes de que nadie use eso como palo, la British Library merece lo contrario, y voy a ser enfático sobre por qué.

Fueron abiertos. Casi nadie más lo es. No tenían ninguna obligación de escribir ni una palabra de aquello. El manual estándar tras un incidente es decir lo mínimo que permita la ley, pasarlo por un equipo de comunicación, negarse a confirmar nada concreto y esperar a que el ciclo de noticias siga adelante. Eso es lo que han hecho la mayoría de las organizaciones de las columnas sin firmar de arriba cuando les tocó, y por eso escribir esta sección siquiera depende de la decisión de una institución de comportarse de otra manera.

En su lugar publicaron una revisión de dieciocho páginas nombrando sus propios fallos, en público, para que otras instituciones pudieran aprender de ellos. Ese es el comportamiento que querrías de cada organización de esta entrada y que consigues de casi ninguna. La razón por la que puedo enseñarte qué falla de verdad dentro de una organización con una brecha es que la British Library decidió contártelo.

Y hay una segunda razón por la que el resto se calla, que es peor que una estrategia de comunicación. Algunas ya no están.

KNP Logistics llevaba moviendo mercancía como Knights of Old desde 1865. En junio de 2023 el grupo Akira entró, cifró la empresa y pidió unos cinco millones de libras. Para septiembre el grupo era insolvente y 730 personas estaban sin trabajo.²¹ Ciento cincuenta y ocho años, fuera en catorce semanas, y nadie de allí está escribiendo lecciones para ti.

Así que cuando las columnas sin firmar de arriba parecen tranquilas, esa tranquilidad está hecha de tres cosas distintas: organizaciones a las que todavía no les han dado, organizaciones a las que les dieron y dijeron lo mínimo que permite la ley, y organizaciones a las que les dieron y ya no están. Solo al primer grupo le queda tiempo para actuar.

Lo que convierte lo que viene ahora en la prueba honesta de mi propio argumento en vez de en un golpe barato. Comprobé su zona:

$ dig +short bl.uk DS
                                          (nothing)
$ dig +short bl.uk DNSKEY
                                          (nothing)

bl.uk está sin firmar. britishlibrary.co.uk también. Dos años después de un ataque de ransomware que cerró la institución durante meses, después de una revisión pública, después de un dictamen de la ICO y después de la ronda de atención a la seguridad más exhaustiva que recibe nunca ninguna organización, el control gratis que lleva una tarde y que un desconocido puede verificar con un comando sigue sin estar hecho.

No lo leo como negligencia, y no creo que los haga peores que las organizaciones sin firmar que no han publicado nada. Lo leo como la prueba más fuerte de esta entrada sobre aquello de lo que ha ido todo esto. Si DNSSEC no se hace aquí, en una organización que ha pasado por el fuego, ha escrito las lecciones y ha tenido al regulador repasándolo todo, entonces no se está saltando porque la gente sea descuidada. Se salta porque nada ni nadie lo pone nunca en la lista.

Esa es la versión honesta del argumento. No las zonas sin firmar causan brechas, que es indemostrable y probablemente falso. Más bien: los controles que nadie de fuera puede ver están, según la evidencia publicada por las organizaciones que han pasado por ello, tan descuidados como el único control que todo el mundo de fuera puede ver. DNSSEC no es la causa. Es la muestra que te dejan tomar.

Que es por lo que la medición merece la pena siquiera. No porque una zona sin firmar sea el fin del mundo por sí sola, sino porque es una de las poquísimas propiedades de seguridad que alguien de fuera puede comprobar honestamente, gratis, sobre cualquiera, sin que le dejen entrar. Trátalo como un detector de humo y no como un veredicto, y luego ve a hacerle las preguntas difíciles a quien lo haga saltar.

La única parte que controlas

Lo que deja la única parte que cualquiera de nosotros controla de verdad. Tu propia zona. No la del NCSC, ni la de Microsoft, ni la de tu banco.

Ve y pregúntale a tu padre si responde por ti:

dig +short yourdomain.uk DS

Si eso vuelve vacío, no estás firmado, y en la mayoría del DNS gestionado de 2026 el arreglo es un interruptor y un registro DS en tu registrador. Actívalo, y luego vigila la caducidad igual que ya vigilas tus certificados, porque esa es la disciplina que la cosa necesita de verdad.

Ese es el trabajo entero. Un registro, y una fecha en tu monitorización.

Así que, por favor, haz al menos esta. No porque venga un regulador, porque para la mayoría de vosotros no viene, y no porque nadie os vaya a dar las gracias, porque no las van a dar. Hazlo porque no viene nadie, y un estándar que mantienes cuando nadie comprueba es el único tipo de estándar que valió algo alguna vez.

Treinta y nueve secretarios de junta parroquial y un espía lo consiguieron. Espabila y ponte a ello.