DNSSEC falla cerrada: SERVFAIL sin aviso previo

En pocas palabras: Cuando una firma RRSIG vence o el registro DS no coincide con la DNSKEY publicada tras una rotación de claves, el resolver validante devuelve SERVFAIL en lugar de una advertencia: así lo exige el RFC 4035, que prohíbe entregar datos no verificados y hace desaparecer el dominio completo del DNS.

Cuando una firma DNSSEC se rompe o vence, tu dominio no muestra ningún aviso: desaparece. Un resolver validante responde SERVFAIL y se niega a entregar la IP. Ese comportamiento, conocido como falla cerrada, tumba zonas completas sin que medie ataque alguno.

DNSSEC (Domain Name System Security Extensions) es el conjunto de extensiones criptográficas del protocolo DNS que permite a un resolver verificar que la respuesta recibida proviene de la zona auténtica y no fue falsificada en tránsito. Cuando esa validación falla, DNSSEC opera en modo de falla cerrada y devuelve SERVFAIL, tal como lo describen las guías técnicas de Microsoft Learn e IBM Think.

¿Qué significa que DNSSEC falle cerrado y por qué es distinto a otros controles de seguridad?

Que DNSSEC falle cerrado significa esto: si la criptografía de una zona firmada deja de validar, el resolver no entrega ninguna dirección. Devuelve SERVFAIL y corta la historia. No hay candadito con advertencia ni botón de “continuar de todos modos”. Para quien consulta, el dominio dejó de existir.

Comparalo con el resto de tu stack. Dejá vencer un header HSTS y el sitio igual carga. Dejá caducar una política CSP y la página renderiza. Dejá vencer el certificado TLS y el servidor sigue respondiendo: el navegador tira una advertencia que el usuario puede saltear. La protección se degrada, el tráfico sobrevive. El análisis de Merlonix lo resume con precisión: DNSSEC es el único control de la pila que falla cerrado.

Y el radio de impacto es mayor que “la web no abre”. Ponele que la firma vence un viernes a las 17: el sitio no carga, el correo empieza a rebotar porque los registros MX viven en la misma zona, la API que consumen tus integraciones queda inalcanzable, los subdominios de staging también, y tu equipo tarda horas en reaccionar porque el monitor de uptime consulta a un resolver que no valida y sigue dando verde. Se parece más a una caída de registro de dominio que a un certificado vencido: el nombre deja de resolver y todo lo colgado de él se va con él.

¿Por qué DNSSEC devuelve SERVFAIL en lugar de seguir funcionando sin firma?

Porque, para un resolver validante, una firma rota y un ataque son la misma cosa. Si la respuesta llega con una firma inválida, el resolver no tiene forma de distinguir si fue un error operativo o alguien falsificando datos en el camino, y la única jugada segura es rechazarla. Tema relacionado: la demo Online Boutique en Kubernetes.

La mecánica: la raíz firma a los TLD, el TLD firma tu dominio mediante un registro DS guardado en tu registrador, y tu zona firma sus propios registros con una firma RRSIG sobre cada conjunto de registros. Un resolver validante recorre esa cadena desde la raíz hasta tu registro. Si todos los eslabones cierran, marca la respuesta con el flag AD (Authenticated Data) y la entrega. Si algún eslabón está presente pero erróneo, la única salida segura es SERVFAIL. Es una decisión de diseño: el objetivo del protocolo es negarse a servir datos potencialmente falsos, y según IBM, esa verificación criptográfica es justamente lo que DNSSEC agrega al DNS clásico.

¿Alguien te avisa antes? No. El certificado vencido te regala una página de advertencia; el dominio vencido te da NXDOMAIN; la firma rota te da un SERVFAIL que ve media internet y vos no.

¿Qué tres relojes de vencimiento corren contra tu dominio?

Todo dominio serio ya convive con dos fechas de caducidad: la del certificado TLS y la del registro del nombre. DNSSEC mete una tercera, y es la que nadie pone en el calendario. Cada firma RRSIG lleva su propia ventana de validez, que suele ser de unas pocas semanas, y la zona tiene que refirmarse antes de que esas ventanas cierren, como detalla este análisis sobre firmas RRSIG vencidas.

Reloj	Qué vence	Quién lo renueva	Aviso si vence	Efecto
Certificado TLS	El certificado HTTPS	Vos o tu proveedor de hosting	Advertencia del navegador	Sitio visible con warning salteable
Registro de dominio	El contrato del nombre	Vos vía registrador	Mails del registrador y del sistema de dominios	NXDOMAIN
Firma RRSIG	La validez de cada firma	Tu signer de DNS	Ninguno	SERVFAIL en resolvers validantes

El problema del tercer reloj es que no dispara alarma nativa alguna. Nadie te manda un mail cuando una RRSIG entra en zona de riesgo.

¿Cuál es la causa número uno de las fallas DNSSEC?

La rotación de claves mal cerrada encabeza la lista: publicás la DNSKEY nueva, el DS del registrador sigue apuntando a la clave anterior, y la cadena se rompe justo en la costura entre dos sistemas distintos. Es, de lejos, la falla más frecuente.

El detalle perverso es que el DS vive en el panel de tu registrador y las claves viven en tu proveedor de DNS. Son dos vendors y dos paneles distintos. Si registrás el dominio en donweb.com y gestionás la zona en otro proveedor, o al revés, esa costura cruzada es exactamente donde se corta todo (y sí, me ha tocado verlo en producción).

Mucho equipo trata DNSSEC como esa configuración “instalar y olvidarse” (spoiler: no existe). Estos son los caminos de falla típicos: Lo explicamos a fondo en integrar la API de Gemini y en la guía de Google.

• Firmas RRSIG vencidas: el proceso que refirma la zona deja de correr, sea por un pipeline roto, un cambio de proveedor o una zona manual que nadie refirmó tras editarla. Los registros siguen ahí; sus firmas quedaron fuera de validez.
• Migración de proveedor con firma activa: movés la zona, los registros llegan, pero la cadena no: las firmas viejas no coinciden con las claves del nuevo proveedor y el DS todavía confía en la cadena anterior.
• Edición sin refirmar o algoritmo no aceptado: cualquier cambio en un registro firmado sin firma válida posterior queda esperando, como mínimo, a que expire el caché.

Ojo con este dato: la abrumadora mayoría de las caídas por DNSSEC son roturas operativas autoinfligidas, intrusiones casi nunca. El enemigo suele estar en tu propio pipeline.

¿Por qué tu sitio funciona para vos pero no para tus usuarios?

Porque no todos los resolvers validan DNSSEC, y esa diferencia genera reportes contradictorios que transforman una incidencia técnica en un misterio de varias horas.

Cuando la firma se rompe, un resolver validante (Cloudflare 1.1.1.1, Google Public DNS y la mayoría de los resolvers grandes actuales) devuelve SERVFAIL: para esos usuarios el sitio está caído, duro. Pero quien consulta a un resolver sin validación, o pega contra un caché tibio con una respuesta que aún no expiró, navega perfecto. Resultado: la mitad dice que todo muerto, la otra mitad dice que todo bien, y el sector de IT, parado sobre el resolver de la oficina con caché caliente, no ve nada raro. Tu dig local da OK. El monitor, si consulta a un resolver que no valida, sigue en verde.

¿Y cómo se corta este nudo? Con una línea:

dig +dnssec @1.1.1.1 tudominio.com

Zona sana: el header trae el flag AD y la respuesta viene acompañada de registros RRSIG. Zona rota: status SERVFAIL. Como contraste, la misma consulta contra un resolver que no valida te devuelve la dirección sin drama, y esa divisoria confirma el diagnóstico al toque. Para ver la cadena completa y saber qué eslabón falló, existen guías dedicadas a errores SERVFAIL de DNS, además de herramientas como dnsviz.net, que grafica toda la cadena marcando el borde roto.

¿Cómo monitorear DNSSEC desde un resolver validante?

Vigilando la postura DNSSEC desde afuera, de forma continua, y tratando el vencimiento de RRSIG como tratás el vencimiento del certificado: es la misma clase de problema, un artefacto fechado que caduca en calendario y se lleva el dominio puesto. Relacionado: qué son los servidores DNS autoritativos.

• Postura, no solo disponibilidad: preguntale a un resolver validante si el flag AD sigue volviendo, y si una zona firmada pasó a no firmada. Un buen monitor distingue un hipo transitorio (que jamás debe disparar alerta) de una regresión permanente, si no se vuelve ruido que terminás muteando.
• RRSIG al calendario de certificados: misma categoría, mismas consecuencias, mismo tratamiento preventivo.
• DS vs DNSKEY tras cada cambio de clave: verificá que el DS del padre coincida con la DNSKEY hija, porque esa costura entre proveedores es donde se rompen los rollovers.

El propio artículo de Merlonix describe un monitor que lee la postura DNSSEC y TLSA/DANE a través del resolver validante de Cloudflare en cada chequeo, registra lecturas autoritativas solo cuando el resolver efectivamente responde y alerta sobre la señal de bajo ruido que importa: una zona firmada que pasó a no firmada.

¿Qué es el downgrade silencioso de DNSSEC?

Si borrás el DS en el registrador, apagás la firma o perdés DNSSEC en una migración, obtenés el escenario inverso: la zona resuelve bien para todos, pero la protección contra falsificación desapareció. Nada pagina, porque nada está caído. Quedaste sin cobertura y sin enterarte, porque la única forma de detectarlo es vigilar la postura, no el uptime.

Eso sí: esta variante es peor que el SERVFAIL. Una transición de firmada a sin firmar luce idéntica a un día sano en cualquier dashboard de disponibilidad, así que hay que monitorearla como cambio de estado. De yapa, dos vecinos que comparten superficie: los registros TLSA (fijan tu certificado TLS vía DNS y solo tienen sentido con zona firmada) y los CAA (limitan qué autoridades de certificación pueden emitir para tu dominio, heredando por el árbol de nombres, de modo que la política efectiva de un subdominio no siempre es la que pusiste en el apex).

Errores comunes con DNSSEC (y cómo zafarlos)

• Tratarlo como “instalar y olvidarse”: activás DNSSEC, lo celebrás y no lo mirás más durante años. Corrección: revisá vencimientos de RRSIG y coincidencia DS-DNSKEY con la misma disciplina que aplicás a los certificados.
• Probar solo desde tu máquina: tu laptop consulta a un resolver que quizás no valida, con caché tibio encima. Corrección: todo diagnóstico va contra un resolver validante conocido, con dig +dnssec.
• Migrar de proveedor DNS sin plan de rollover: movés la zona primero y pensás en el DS después (o nunca). Corrección: publicá las claves nuevas, esperá que expiren los TTL, actualizá el DS en el registrador y validá con dnsviz antes de dar la migración por cerrada.
• Confundir monitor verde con dominio protegido: el uptime no mide criptografía. Corrección: sumá una alerta específica para la transición firmada → sin firmar.

Preguntas Frecuentes

¿Qué significa que DNSSEC falle cerrada?

Significa que ante una firma inválida o vencida el resolver validante devuelve SERVFAIL y no entrega ninguna dirección IP. No existe modo degradado ni advertencia salteable: para quien consulta, el dominio ya no existe. Te puede servir nuestra cobertura de las mejores plataformas CI/CD para automatizar despliegues.

¿Cuál es la diferencia entre DNSSEC y un certificado TLS?

TLS cifra y autentica la conexión entre navegador y servidor; DNSSEC firma los registros DNS para que el resolver verifique que la respuesta no fue falsificada en tránsito. Fallan distinto: el certificado vencido muestra un aviso salteable, mientras que DNSSEC roto devuelve SERVFAIL y corta el acceso.

¿Cómo sé si mi dominio tiene DNSSEC activo y las firmas válidas?

Corré dig +dnssec @1.1.1.1 tudominio.com. Si la respuesta trae el flag AD en el header y registros RRSIG junto a los valores, la zona está firmada y validando. Si vuelve SERVFAIL, la cadena está rota; si no aparece firma alguna, la zona está sin firmar.

¿Cuáles son las causas más comunes de una falla DNSSEC?

El desajuste entre el DS del registrador y la DNSKEY tras una rotación de claves encabeza la lista, seguido por firmas RRSIG vencidas sin refirmado, migraciones de proveedor que rompen la cadena y ediciones sin refirma posterior. Según el análisis de Merlonix, la mayoría son fallas operativas propias, no ataques.

¿Conviene mantener DNSSEC activado si puede dejar mi web inaccesible?

Sí, siempre que lo monitorees. La protección contra suplantación de respuestas DNS justifica el costo operativo, pero exige vigilar el vencimiento de RRSIG, la coincidencia DS-DNSKEY y la postura desde un resolver validante, porque el fallo no avisa y no afecta a todos por igual.

Conclusión

DNSSEC es el tercer reloj que nadie agenda, con un modo de falla más feo que el del certificado y el del registro: no avisa y no falla abierto, y encima se lo come media internet mientras la otra mitad navega feliz. Acciones concretas para esta semana: corré un dig +dnssec contra 1.1.1.1, verificá que el DS de tu registrador coincida con la DNSKEY de tu zona, poné los vencimientos de RRSIG en el calendario junto a los del certificado y sumá monitoreo de postura desde afuera. Acordate que la firma rota no va a avisarte: va a hacer que tu dominio deje de existir mientras tu dashboard sigue en verde.

Fuentes

• Merlonix (dev.to) – Análisis original: DNSSEC fails closed, una firma rota es SERVFAIL
• Microsoft Learn – Descripción general de DNSSEC
• IBM Think – Qué es DNSSEC y cómo funciona
• dominios.es – Protocolo de seguridad DNSSEC en la gestión de dominios .es
• Allan Ninal – Firmas RRSIG vencidas y su relación con los errores SERVFAIL