Ir al contenido principal

SERVFAIL tras activar DNSSEC: diagnóstico y corrección

Por CaptainDNS
Publicado el 25 de febrero de 2026

Diagnóstico SERVFAIL DNSSEC: árbol de decisión para identificar y corregir la causa de un SERVFAIL tras activar DNSSEC
TL;DR
  • Un SERVFAIL relacionado con DNSSEC significa que el resolvedor rechazó la respuesta DNS porque un eslabón de la cadena de confianza es inválido
  • Cinco causas cubren la práctica totalidad de los casos: DS ausente, DS incorrecto, RRSIG expirada, algoritmo incompatible, caché contaminada
  • Tres comandos dig bastan para aislar el problema (consulta el árbol de decisión al final del artículo)
  • Verifica que tu cadena está intacta con nuestro DNSSEC Checker (consulta el plan de acción al final del artículo)

Acabas de activar DNSSEC en tu registrar. Las primeras pruebas pasan. Pero unas horas después, tus usuarios reportan que el sitio es inaccesible. El diagnóstico: SERVFAIL.

El SERVFAIL no es un problema de servidor. Es el resolvedor DNS el que se niega a devolver la respuesta porque la validación DNSSEC falló. Tu servidor funciona, pero el resolvedor lo bloquea.

Esta guía cubre los cinco escenarios de SERVFAIL relacionados con DNSSEC, con el comando de diagnóstico y la corrección exacta para cada uno.

SERVFAIL y DNSSEC: el mecanismo

Cuando un resolvedor validante (1.1.1.1, 8.8.8.8, 9.9.9.9) recibe una respuesta DNS para un dominio firmado con DNSSEC, verifica la cadena de confianza completa: ancla de confianza, DS record, DNSKEY, RRSIG.

Si una verificación falla, el resolvedor marca la respuesta como BOGUS y devuelve SERVFAIL al cliente. El sitio se vuelve inaccesible para todos los usuarios cuyo resolvedor valida DNSSEC (aproximadamente el 38 % de las consultas DNS mundiales, según APNIC).

La dificultad: un SERVFAIL no indica por qué falló la validación. Hay que diagnosticarlo manualmente.

Diagnóstico rápido: tres comandos

Antes de analizar cada escenario, estos son los tres comandos que bastan en la mayoría de los casos.

Comando 1: verificar el DS record

dig DS captaindns.com +short

Si el comando no devuelve nada, no hay DS record en el TLD. La cadena no está establecida.

Comando 2: comparar DS y DNSKEY

dig DNSKEY captaindns.com +short

El DS record contiene un hash de la KSK (flag 257). Si el hash no corresponde a ninguna DNSKEY publicada, el DS es incorrecto.

Comando 3: verificar las firmas

dig A captaindns.com +dnssec +cd

El flag +cd (Checking Disabled) le pide al resolvedor que devuelva la respuesta sin validar DNSSEC. Si la respuesta llega con +cd pero no sin él, el problema está relacionado con DNSSEC.

Las cinco causas de SERVFAIL tras DNSSEC

Causa 1: DS record ausente

Síntoma: dig DS captaindns.com +short no devuelve nada.

Explicación: firmaste tu zona (las DNSKEY y RRSIG existen) pero el DS record no se publicó en el TLD. El resolvedor no puede vincular tu zona con la zona padre.

Estado DNSSEC: INSECURE (no BOGUS). El resolvedor no valida, pero tampoco bloquea. Este caso solo provoca un SERVFAIL si el resolvedor tiene un DS en caché de una configuración anterior.

Corrección:

  1. Obtén el DS record de tu proveedor DNS (Cloudflare, Route 53, OVHcloud)
  2. Agrégalo en la interfaz de tu registrar (sección DNSSEC)
  3. Espera la propagación (TTL del DS en el TLD, normalmente 24-48h)

Verificación:

dig DS captaindns.com +short
# Debe devolver el DS record con Key Tag, Algorithm, Digest Type, Digest

Causa 2: DS record incorrecto

Síntoma: el DS record existe pero el hash no corresponde a ninguna KSK publicada.

Explicación: el DS en el TLD contiene un hash que no corresponde a la KSK de tu zona. Causas frecuentes:

  • Error de copiar y pegar durante la entrada manual
  • Rotación de la KSK sin actualización del DS
  • DS generado con un algoritmo de hash incorrecto (SHA-1 en lugar de SHA-256)

Estado DNSSEC: BOGUS. El resolvedor devuelve SERVFAIL.

Diagnóstico:

# Obtener el DS del TLD
dig DS captaindns.com +short
# Ejemplo: 12345 13 2 ABC123...

# Obtener las DNSKEY
dig DNSKEY captaindns.com +short
# Buscar la KSK (flag 257)
# Verificar que el Key Tag (12345) corresponde

Corrección:

  1. Desde tu proveedor DNS, genera el DS record correcto
  2. En la interfaz del registrar, elimina el DS antiguo y agrega el nuevo
  3. Si tu registrar soporta CDS/CDNSKEY (RFC 7344), la actualización puede ser automática

Verificación:

dig captaindns.com +dnssec | grep flags
# El flag "ad" debe estar presente

Causa 3: firmas RRSIG expiradas

Síntoma: la respuesta DNS contiene RRSIG cuya fecha de expiración ya pasó.

Explicación: cada firma RRSIG tiene un período de validez (típicamente de 7 a 30 días). Si tu proveedor DNS no renueva las firmas antes de que expiren, los resolvedores las rechazan.

Estado DNSSEC: BOGUS. SERVFAIL en todos los registros cuya firma expiró.

Diagnóstico:

dig A captaindns.com +dnssec +cd
# Examinar el campo RRSIG: inception y expiration
# Formato: RRSIG A 13 2 300 20260315120000 20260301120000 12345 captaindns.com. ABC...
#                               ^^^^^^^^^^^^^^^^ expiration
#                                                ^^^^^^^^^^^^^^^^ inception

Causas frecuentes:

  • BIND o PowerDNS autogestionado sin renovación automática configurada
  • Error en el cron de re-firma
  • Migración DNS sin transferir las claves de firma

Corrección:

  1. Si es DNS gestionado: contacta al soporte del proveedor
  2. Si es BIND autogestionado: reinicia la firma con rndc sign captaindns.com
  3. Si es PowerDNS: ejecuta pdnsutil rectify-zone captaindns.com

Causa 4: algoritmo incompatible

Síntoma: el DS record especifica un algoritmo diferente al utilizado por la DNSKEY.

Explicación: el DS record indica, por ejemplo, el algoritmo 8 (RSA/SHA-256) mientras que la DNSKEY usa el algoritmo 13 (ECDSA P-256). El resolvedor no puede verificar la correspondencia.

Estado DNSSEC: BOGUS. SERVFAIL.

Diagnóstico:

# Verificar el algoritmo del DS
dig DS captaindns.com +short
# Formato: KeyTag Algorithm DigestType Digest
# Ejemplo: 12345 8 2 ABC...  (algoritmo 8 = RSA/SHA-256)

# Verificar el algoritmo de la DNSKEY
dig DNSKEY captaindns.com +short
# Formato: Flags Protocol Algorithm PublicKey
# Ejemplo: 257 3 13 ABC...  (algoritmo 13 = ECDSA P-256)

Si los números de algoritmo difieren entre el DS y la DNSKEY (flag 257), esa es la causa.

Corrección:

  1. Regenera el DS record desde tu proveedor DNS (usará el algoritmo correcto)
  2. Actualiza el DS en el registrar
  3. Espera la propagación

Causa 5: caché del resolvedor (falso SERVFAIL)

Síntoma: SERVFAIL intermitente. Algunos resolvedores devuelven SERVFAIL y otros no.

Explicación: el resolvedor tiene en caché una respuesta antigua o un DS record anterior. Tras una modificación DNSSEC (activación, rotación de clave, cambio de proveedor DNS), la caché del resolvedor puede contener datos inconsistentes.

Diagnóstico:

# Probar con un resolvedor diferente
dig A captaindns.com @1.1.1.1 +dnssec
dig A captaindns.com @8.8.8.8 +dnssec
dig A captaindns.com @9.9.9.9 +dnssec

Si algunos resolvedores funcionan y otros no, es un problema de caché.

Corrección:

  1. Espera la expiración del TTL (verifica el TTL del DS record en el TLD)
  2. Purga la caché si es posible:

Prevención: antes de cualquier modificación DNSSEC, reduce el TTL del DS record con 24h de antelación (si tu registrar lo permite).

Árbol de decisión SERVFAIL DNSSEC: identificar la causa con tres comandos dig

Prevenir los SERVFAIL DNSSEC

Tres prácticas reducen el riesgo de ruptura:

DNS gestionado en lugar de autogestionado

Los proveedores de DNS gestionado (Cloudflare, Route 53, OVHcloud, Google Cloud DNS) manejan la firma automáticamente: rotación de claves, renovación de RRSIG, publicación del DS vía CDS/CDNSKEY. El riesgo de SERVFAIL es prácticamente nulo con un DNS gestionado.

Doble DS durante las transiciones

Durante una rotación de KSK, publica ambos DS records (antiguo + nuevo) en el registrar. Espera la propagación completa del nuevo DS antes de eliminar el antiguo. Nunca elimines el DS anterior sin haber verificado que el nuevo se propagó correctamente.

Supervisión continua

Verifica regularmente la propagación DNS de tu configuración DNSSEC. Un DS incorrecto o una firma expirada pueden ocurrir silenciosamente. Una alerta automática sobre el estado DNSSEC de tu dominio permite detectar un problema antes de que tus usuarios lo reporten.

Proceso de corrección SERVFAIL DNSSEC: de la detección a la verificación posterior

Plan de acción ante un SERVFAIL

  1. Confirmar que DNSSEC es la causa: ejecuta dig captaindns.com +cd; si la respuesta llega con +cd pero no sin él, DNSSEC es la causa
  2. Identificar el eslabón roto: verifica DS, DNSKEY y RRSIG con los tres comandos de diagnóstico
  3. Aplicar la corrección: sigue el escenario correspondiente (DS ausente, DS incorrecto, RRSIG expirada, algoritmo, caché)
  4. Verificar la reparación: espera el TTL y comprueba que el flag ad está presente con dig captaindns.com +dnssec
  5. Documentar el incidente: registra la causa, la corrección y el tiempo de resolución para agilizar diagnósticos futuros

Ejecuta un diagnóstico DNSSEC completo de tu dominio para verificar que cada eslabón está en su lugar.

Guías de DNSSEC relacionadas

FAQ

¿Qué es un SERVFAIL DNS?

SERVFAIL (Server Failure) es un código de respuesta DNS (RCODE 2) que indica que el resolvedor no pudo obtener una respuesta válida. En el contexto de DNSSEC, un SERVFAIL significa que la validación criptográfica falló: el resolvedor rechazó la respuesta porque un eslabón de la cadena de confianza es inválido.

¿Cuál es la diferencia entre SERVFAIL y NXDOMAIN?

NXDOMAIN significa que el dominio no existe. SERVFAIL significa que el dominio probablemente existe, pero el resolvedor no pudo validar la respuesta. Con DNSSEC, un SERVFAIL indica un problema de validación (DS incorrecto, firma expirada), no un dominio inexistente.

¿Cómo saber si un SERVFAIL es causado por DNSSEC?

Usa el flag +cd (Checking Disabled) en tu comando dig: dig captaindns.com +cd. Si la respuesta llega con +cd pero no sin él, DNSSEC es la causa del SERVFAIL. Sin +cd, el resolvedor valida DNSSEC y bloquea la respuesta.

¿Cuánto tiempo se tarda en corregir un SERVFAIL DNSSEC?

La corrección en sí toma unos minutos (agregar o modificar el DS record). La propagación puede tardar de 1 a 48 horas según el TTL del DS record en el TLD. Durante ese tiempo, los resolvedores que tengan el valor antiguo en caché seguirán devolviendo SERVFAIL.

¿Hay que desactivar DNSSEC de urgencia si hay SERVFAIL?

No. Desactivar DNSSEC de urgencia (eliminar el DS record sin desactivar la firma de zona) puede empeorar el problema. Identifica primero la causa exacta. Si el DS record es incorrecto, corrígelo. Solo desactiva DNSSEC si no logras identificar la causa y el sitio es crítico.

¿Por qué el SERVFAIL no afecta a todos los usuarios?

Solo los resolvedores validantes (que verifican DNSSEC) devuelven SERVFAIL. Los resolvedores no validantes ignoran las firmas y devuelven la respuesta normalmente. Además, los resolvedores que aún tienen la respuesta antigua en caché pueden seguir funcionando hasta que expire el TTL.

¿Cómo verificar que la corrección DNSSEC funcionó?

Ejecuta dig captaindns.com +dnssec | grep flags. Si el flag ad (Authenticated Data) está presente, la cadena de confianza está validada. Prueba con varios resolvedores (1.1.1.1, 8.8.8.8, 9.9.9.9) para confirmar que la propagación se completó.

¿El DNS gestionado elimina el riesgo de SERVFAIL DNSSEC?

Casi por completo. Los proveedores de DNS gestionado (Cloudflare, Route 53, OVHcloud) manejan automáticamente la firma, la rotación de claves y la renovación de RRSIG. El único riesgo restante es un DS record incorrecto en el registrar, lo que puede ocurrir durante la configuración inicial o una transferencia de dominio.

Glosario

  • SERVFAIL: código de respuesta DNS (RCODE 2) que indica que el resolvedor no pudo completar la consulta. En el contexto de DNSSEC, señala un fallo de validación.
  • BOGUS: estado interno del resolvedor cuando la validación DNSSEC falla. El resolvedor devuelve SERVFAIL al cliente.
  • INSECURE: estado de un dominio cuya zona está firmada pero sin DS record en el TLD. El resolvedor no valida pero tampoco bloquea.
  • DS record: registro en el TLD que contiene un hash de la KSK. Eslabón entre la zona y la zona padre.
  • RRSIG: firma criptográfica de un registro DNS con un período de validez definido.
  • +cd (Checking Disabled): flag dig que le pide al resolvedor no validar DNSSEC, útil para diagnosticar si DNSSEC causa un SERVFAIL.

Fuentes

Artículos relacionados