Entrevista de redes: ¿Cómo solucionar el error SERVFAIL tras un rollover de DNSSEC?

Planteamiento y cuándo se aplica

A las 21:00 UTC, example.com realiza un rollover de claves DNSSEC y cambia el registro A para api.example.com de 192.0.2.20 a 192.0.2.40. Diez minutos después, los clientes que utilizan ciertos resolvers recursivos con validación reciben SERVFAIL. Añadir +cd a la misma consulta del resolver devuelve la nueva dirección y un RRSIG, y las consultas directas a los servidores autoritativos también reciben respuestas. Otros clientes continúan utilizando la dirección antigua. Actualmente, el padre publica un DS con key tag 18200, mientras que la zona hija publica únicamente un DNSKEY con key tag 51900. Diagnostica, recupera y verifica el incidente sin abandonar el límite de validación de DNSSEC ni distribuir respuestas no confiables a los usuarios.

El dominio, las direcciones, los key tags, los horarios y los cambios son supuestos para la entrevista. 192.0.2.0/24 es un bloque de direcciones para documentación. La tarea principal consiste en deducir el estado de cada capa de resolución DNS y la cadena de confianza de DNSSEC a partir de síntomas observables. No debe inferirse una caída de la aplicación únicamente a partir de SERVFAIL. La pregunta encaja en roles de SRE, infraestructura, redes, seguridad, backend e ingeniería de software general, por lo que su categoría es general.

Un debate público de 2025 sobre entrevistas para roles sénior aún considera que el conocimiento de DNS y DNSSEC es material relevante para entrevistas. Dicha evidencia establece un contexto de entrevista actual; no determina una frecuencia ni una pregunta fija de un empleador. El informe de 2026 de DENIC sobre la caída de DNS de .de documenta un defecto en el rollover que provocó que la mayoría de las firmas no fueran verificables y causó que los resolvers con validación rechazaran las delegaciones afectadas. Por lo tanto, los fallos de claves, firmas y validación siguen siendo operativamente reales.

El artículo existente sobre «qué ocurre cuando escribes una URL» cubre el caso normal en el que un cliente delega el trabajo recursivo y las cachés acortan la ruta. El artículo de SSRF se enfoca en autorizar direcciones resueltas y cerrar brechas de DNS rebinding. Esta pregunta se centra en los registros DS del padre, los registros DNSKEY/RRSIG del hijo, el estado de validación, el orden de recuperación seguro y la verificación en múltiples resolvers. Su capa de fallo y sus invariantes de seguridad son distintos.

Qué evalúa el entrevistador

La primera señal es el diagnóstico por capas. Un fallo en la resolución de nombres puede originarse en el stub local, en un resolver recursivo corporativo o público, en la delegación del padre, en los servidores autoritativos, en la validación DNSSEC o en los datos finales de A, AAAA o CNAME. Una respuesta sólida mantiene constantes el nombre de la consulta, el tipo, la hora y el resolver, recopila el RCODE, la respuesta, el TTL, los datos de autoridad y los registros DNSSEC en cada capa, e identifica el primer punto donde divergen las observaciones.

La segunda señal es la interpretación precisa de los códigos de respuesta. NXDOMAIN significa que la cadena autoritativa afirma que el nombre consultado no existe. NOERROR con una respuesta vacía puede significar que el nombre existe pero no tiene registros de ese tipo. Un timeout significa que no llegó ninguna respuesta utilizable dentro del tiempo límite. REFUSED significa que el servidor rechazó la consulta. SERVFAIL es un fallo genérico del servidor. Un fallo en la validación DNSSEC puede producir SERVFAIL, pero un único código de estado no puede demostrar esa causa por sí solo.

La tercera señal es la comprensión de la cadena de confianza. Un registro DS reside en el punto de delegación del lado del padre y conecta la cadena confiable del padre con un DNSKEY hijo. Los registros RRSIG firman los RRsets en la zona hija, mientras que el validador también comprueba los algoritmos, los digests, los límites temporales de la firma y el trust anchor. Un key tag ayuda a localizar una clave candidata; no es una prueba criptográfica. La respuesta debe verificar que el digest del DS corresponda a un DNSKEY real y que las claves publicadas validen las firmas relevantes.

La cuarta señal es la comparación controlada. Frente al mismo resolver recursivo, una consulta normal con +dnssec que falla mientras que una consulta con +cd devuelve registros sin procesar apunta firmemente a la ruta de validación. CD solicita al resolver que desactive la comprobación para esa consulta y resulta útil para el diagnóstico. No hace que los datos devueltos sean confiables y no es un bypass para producción. Un bit AD de un resolver validador de confianza puede indicar datos autenticados. La ausencia de AD también puede reflejar la solicitud del cliente, la política del resolver o el límite de confianza, por lo que debe interpretarse junto con el resto de la evidencia.

Por último, el entrevistador busca disciplina en la recuperación. Si la clave antigua a la que hace referencia el DS actual del padre se retiró demasiado pronto, la vía segura más rápida suele ser restaurar el DNSKEY y las firmas válidas que el DS actual puede autenticar, para luego reanudar el rollover con una ventana de solapamiento. Desactivar globalmente la validación, purgar cachés arbitrarias o editar repetidamente el registro A amplía el riesgo. Tras la recuperación, los TTL existentes aún deben converger, y validadores independientes deben demostrar tanto una cadena sólida como una aplicación funcional.

Preguntas para clarificar antes de responder

• ¿El impacto afecta a un solo nombre, a toda la zona o a muchas zonas bajo un mismo TLD? El alcance determina si se debe comenzar por un cambio en la zona hija, el proveedor autoritativo o un incidente en el padre/registro.
• ¿Qué resolver recursivo utiliza realmente el cliente afectado? El DNS cifrado del navegador, los forwarders corporativos, las VPN y la configuración del sistema operativo pueden enviar a los clientes por rutas distintas desde la misma red.
• ¿Cuáles son el RCODE, el EDE, el tipo de consulta y la hora de cada fallo? Un éxito en A con un fallo en AAAA, un salto CNAME roto o un fallo limitado a resolvers con validación generan ramas de diagnóstico diferentes.
• ¿Cuáles eran los valores de NS, DS, DNSKEY, RRSIG y TTL antes y después del cambio? El orden del rollover, la vida máxima en caché y las claves antiguas recuperables determinan la mitigación.
• ¿Todos los servidores autoritativos devuelven el mismo serial SOA y RRsets firmados? El desfase de versiones entre autoridades puede generar resultados intermitentes; un único servidor no es representativo de toda la zona.
• ¿Son correctos los relojes del resolver y del firmante? Los registros RRSIG tienen horas de inicio (inception) y expiración, por lo que un error significativo de reloj puede causar fallos de validación.
• ¿Puede la IP antigua seguir atendiendo tráfico de forma segura? En caso afirmativo, mantén la compatibilidad durante la convergencia del TTL. Si no es así, gestiona ese riesgo de conexión por separado, ya que el DNS no puede revocar respuestas en caché de forma forzada.
• ¿Quién controla el DS del padre y los cambios de emergencia? El registrador, el registro, el proveedor de DNS y el equipo de guardia interno tienen diferentes permisos y tiempos de respuesta.

Estructura de respuesta en 30 segundos

«Identificaría el resolver recursivo del cliente que falla y registraría el RCODE, EDE, datos A/AAAA/CNAME, TTL y la marca de tiempo. Frente a ese mismo resolver, recibir SERVFAIL normalmente y datos con +cd me orienta hacia la ruta de validación DNSSEC. Obtendría el DS del padre y DNSKEY, RRSIG y SOA de cada servidor autoritativo, comparando luego el digest, el algoritmo, los tiempos de firma y la consistencia entre nodos. Aquí, el DS del padre no tiene un DNSKEY hijo coincidente, lo cual es coherente con haber retirado la clave antigua demasiado pronto. En primer lugar, restauraría la clave y firmas válidas conocidas que coincidan con el DS actual. Una vez que múltiples validadores devuelvan respuestas autenticadas, monitorizaría la convergencia del TTL e incorporaría rollover con solapamiento, validación previa a la publicación, alertas de expiración de firmas y comprobaciones sintéticas desde múltiples ubicaciones».

Respuesta detallada paso a paso

Paso 1: Establecer el límite del fallo y los controles

Registra la hora, la red del cliente, el resolver recursivo real, el nombre de la consulta y el tipo de consulta para un fallo. Omite las cachés de la aplicación y del navegador y consulta el resolver que utiliza el cliente. Luego, elige un resolver validador independiente como control. No cambies el nombre, el tipo y el resolver simultáneamente, ya que la diferencia dejaría de aislar una variable.

dig @<affected-resolver> api.example.com A +dnssec
dig @<affected-resolver> api.example.com AAAA +dnssec
dig @<control-resolver> api.example.com A +dnssec

Conserva el status, los flags, Answer, Authority, Additional, el TTL y cualquier Extended DNS Error (EDE) de la respuesta completa. Si A valida mientras AAAA falla, inspecciona AAAA y su cadena CNAME. Si todos los tipos dan timeout, inspecciona primero la alcanzabilidad de red, el puerto 53, la disponibilidad autoritativa y el manejo del tamaño de paquetes. Si solo falla un resolver recursivo, su caché, política, reloj o cadena de reenvío siguen siendo candidatos.

Que haya clientes que aún alcancen la IP antigua no es una evidencia contradictoria. Un RRset A antiguo puede reutilizarse hasta que expire su TTL, y su firma acompañante aún puede ser válida. Un TTL no puede reducirse retroactivamente tras su publicación, por lo que se debe mantener el endpoint antiguo seguro y compatible durante la ventana conocida de caché.

Paso 2: Utilizar una comparación con CD para entrar en la rama de DNSSEC

Repite el mismo nombre y tipo contra el mismo resolver que falla, con el bit CD activado:

dig @<affected-resolver> api.example.com A +dnssec
dig @<affected-resolver> api.example.com A +dnssec +cd

Si la consulta normal devuelve SERVFAIL pero con +cd devuelve registros A, DNSKEY o RRSIG, el fallo de validación se convierte en la hipótesis principal. La guía de resolución de problemas de dominios de Google Public DNS utiliza este mismo contraste (Status 2 con éxito cuando la validación está deshabilitada) para identificar problemas probables de DNSSEC, y los Extended DNS Errors pueden proporcionar un motivo más específico. Continúa inspeccionando la ruta directa, ya que los timeouts de autoritativos, los bucles de delegación y otros fallos del servidor también pueden producir SERVFAIL.

+cd expone datos que el resolver rechazaría de otro modo. Apuntar la aplicación a un resolver sin validación o desactivar DNSSEC globalmente convierte un incidente de disponibilidad en un riesgo de integridad. Si un incident commander utiliza una excepción de validación durante una caída generalizada en un proveedor upstream, esta debe tener un alcance de dominio reducido, un límite de tiempo, un riesgo registrado y criterios explícitos de salida.

Paso 3: Inspeccionar la delegación, los datos autoritativos y las firmas por separado

Primero, utiliza una traza para enumerar la ruta real a través de la delegación de la raíz, del padre y del hijo. Una traza es una observación de la ruta de consulta, no un resultado completo de validación criptográfica. Consulta el DS directamente a una autoridad del padre, y consulta DNSKEY, SOA y el RRset de negocio a cada autoridad hija.

dig +trace example.com DS +dnssec
dig @<parent-authoritative> example.com DS +dnssec
dig @<child-authoritative-1> example.com DNSKEY +dnssec
dig @<child-authoritative-1> api.example.com A +dnssec
dig @<child-authoritative-1> example.com SOA +dnssec

Repite las consultas para cada autoridad y compara el conjunto de NS, glue, serial SOA, RRset de DNSKEY y registros RRSIG. Que un servidor autoritativo devuelva A y RRSIG demuestra que está sirviendo datos. Los servidores autoritativos generalmente no validan la cadena completa desde el trust anchor del padre en nombre del solicitante. Por lo tanto, el éxito en la autoridad directa y el fallo en la validación recursiva pueden coexistir.

Comprueba que el propietario del DS del padre, el algoritmo, el tipo de digest y el digest correspondan a un DNSKEY hijo; que el RRset de DNSKEY tenga una firma actualmente válida; que el RRSIG del RRset A de negocio tenga un key tag, algoritmo, inicio y expiración plausibles; y que cada zona firmada en una cadena CNAME pueda establecer una cadena. Un validador independiente puede identificar el nodo con fallos, tras lo cual los registros sin procesar deberían confirmarlo.

En este escenario, el key tag 18200 del DS del padre no tiene candidato en el RRset DNSKEY hijo, y su digest no coincide con la clave actual 51900. La correlación con la hora del cambio demuestra que la KSK/DNSKEY antigua se eliminó antes de que el DS del padre completara una transición segura. El desajuste del tag es una pista; la comparación del digest y la validación de firmas completan la prueba.

Paso 4: Recuperar el servicio dentro del límite de seguridad

Congela los rollovers automáticos y los cambios de DNS no relacionados. Conserva el registro de cambios, la instantánea de la zona, los identificadores de claves y las respuestas fallidas. Si la clave privada anterior permanece en el sistema de claves controlado, restaura su DNSKEY y genera firmas válidas conocidas que establezcan una cadena a través del DS actual del padre. Esto suele ser más rápido que esperar un cambio en el padre. Valida la cadena completa de forma aislada antes de publicar el mismo estado en todas las autoridades.

Si la clave antigua es irrecuperable, los responsables de DNS y seguridad deben coordinar una corrección del DS del padre con el registrador y tener en cuenta la propagación. Eliminar el DS devuelve la zona hija a un estado no firmado, debilita su garantía de autenticación y aun así conlleva latencia por caché y cambios en el padre. Es una opción de recuperación aprobada, documentada y acotada, no un atajo informal. Generar una nueva clave conservando solo el mismo key tag no funcionará: el digest no coincidirá.

Si el endpoint A antiguo sigue siendo seguro, continúa sirviéndolo durante la ventana de TTL del RRset antiguo. Los endpoints antiguo y nuevo deben utilizar configuraciones críticas y políticas de autenticación compatibles. El vaciado de caché solo puede afectar a los resolvers bajo el control del operador, por lo que la recuperación no puede depender de una purga global inexistente.

Paso 5: Demostrar que el DNS y la aplicación se han recuperado

Consulta el nombre corregido desde resolvers recursivos con validación independientes y diferentes regiones. Confirma que SERVFAIL haya desaparecido, que la respuesta sea la esperada y que exista un resultado de validación confiable. Luego, realiza una resolución completa con un resolver con caché limpia o una herramienta de validación independiente para que una caché antigua exitosa no oculte el defecto. Compara los seriales SOA, los registros DNSKEY y las firmas en cada autoridad y registra el tiempo de vida restante de las firmas.

A continuación, valida la aplicación: los health checks, certificados TLS, solicitudes autenticadas y las API críticas deben funcionar tanto en la dirección antigua como en la nueva. Un éxito en DNS con un nuevo endpoint mal configurado constituye una recuperación incompleta. Observa la tasa de fallos, el tráfico a la dirección antigua, los RCODE, la latencia de resolución y los errores de negocio durante las ventanas originales de TTL y firmas hasta que el tráfico de cachés antiguas converja. Cubre A, AAAA, CNAME y cualquier otro tipo de registro utilizado por el servicio.

Conserva una cronología de la publicación, el primer fallo de validación, la evidencia de la causa raíz, las decisiones de seguridad, la recuperación de padre/hijo y la convergencia del TTL. Cierra el incidente únicamente después de que tanto la validación independiente como los resultados del usuario se hayan recuperado.

Paso 6: Convertir el rollover en un proceso de despliegue falsable

Publica previamente la nueva DNSKEY para que los servidores autoritativos y las cachés puedan observarla. Actualiza el DS del padre mientras la cadena antigua sigue siendo válida, espera a los TTL relevantes y al flujo de trabajo del registro, valida continuamente las cadenas antigua y nueva admisibles, y solo entonces retira el DS, las firmas y la clave antiguas. La secuencia exacta debe seguir el procedimiento admitido por el proveedor y el registro; un número fijo de minutos de espera no es una regla universal.

Las puertas de enlace de despliegue (release gates) deben demostrar que cada firmante de producción publica datos de DNSKEY y firmas mutuamente válidos y compatibles; que el DS del padre apunta a la clave prevista; que los registros RRSIG tienen un tiempo de vida restante adecuado; que una muestra de RRsets de negocio valida correctamente; y que las alertas llegan a un responsable humano. El informe de 2026 de DENIC también muestra un defecto que requería múltiples HSM y que no se detectó en una prueba con un solo HSM, mientras que las alertas de validación existentes no se gestionaron correctamente. Por lo tanto, la prevención requiere cobertura de la topología de producción y un circuito de alertas puesto en práctica.

Ejemplo de respuesta de alta calidad

«Primero identificaría el resolver recursivo, el tipo de consulta y la marca de tiempo utilizados por un cliente que falla, y guardaría la respuesta completa. Para el mismo resolver, api.example.com A +dnssec devuelve SERVFAIL, mientras que añadir +cd devuelve A y RRSIG. Ese contraste controlado da prioridad a la validación DNSSEC. La respuesta con CD sigue siendo no confiable y no se puede entregar a la aplicación de producción.

Utilizaría +trace para observar la delegación real, consultaría el DS directamente al padre y consultaría DNSKEY, SOA, A y RRSIG a cada autoridad hija. Comprobaría si el algoritmo y el digest del DS del padre coinciden con una DNSKEY, si todas las autoridades comparten el serial, si cada key tag y rango de tiempo de RRSIG son plausibles, y dónde un validador independiente clasifica la cadena como bogus. Una respuesta directa de la autoridad no demuestra la cadena, porque ese servidor entrega registros mientras que el validador recursivo aún debe conectar la clave hija con el DS del padre y un trust anchor.

El DS 18200 del escenario no tiene una DNSKEY coincidente y su digest no coincide con la clave 51900, lo que demuestra que la clave antigua se retiró demasiado pronto. Congelaría los cambios, restauraría la DNSKEY antigua y las firmas válidas que coincidan con el DS actual desde el sistema de claves controlado, las validaría de forma aislada y publicaría un estado consistente desde todas las autoridades. Si la clave antigua no se puede restaurar, el responsable de seguridad y el registrador deben coordinar una corrección del DS. No desactivaría la validación globalmente ni asumiría que existe un vaciado de caché global.

Tras la recuperación, ejecutaría consultas en frío y en caliente desde múltiples regiones y resolvers con validación independientes, verificando RCODE, estado autenticado, A/AAAA/CNAME, TTL y seriales de las autoridades. También probaría TLS y las API críticas tanto en la dirección antigua como en la nueva. Los clientes pueden usar legítimamente la IP antigua durante su TTL, por lo que ese endpoint se mantiene compatible hasta que el tráfico converja. Por último, añadiría al proceso de rollover la publicación previa de claves, cadenas solapadas, un release gate para el DS del padre, monitorización de expiración de firmas, comprobaciones de consistencia multiautoridad, pruebas en topología de producción y entrega verificada de alertas».

Errores comunes

• Modificar los servidores de aplicaciones inmediatamente tras ver SERVFAIL → El DNS no ha producido una dirección confiable, por lo que es posible que la aplicación no reciba tráfico → Aísla el resolver e inspecciona primero el RCODE, el EDE y la delegación.
• Tratar el éxito con +cd como datos confiables → CD omite la validación y puede devolver datos dañados → Utilízalo solo como control, luego valida DS, DNSKEY y RRSIG.
• Descartar DNSSEC porque las consultas directas a la autoridad funcionan → Una autoridad puede servir datos que no se validan a través de la cadena del padre → Prueba la disponibilidad de datos y la validación criptográfica por separado.
• Comparar únicamente los key tags → Un key tag selecciona candidatos pero no reemplaza la validación de algoritmo y digest → Calcula o valida de forma independiente la relación completa de DS a DNSKEY.
• Calificar la IP antigua y SERVFAIL como un único fallo de caché → Una caché antigua válida y una nueva validación fallida pueden coexistir → Segmenta las observaciones por resolver, antigüedad de la caché y TTL.
• Eliminar la clave antigua de inmediato durante el rollover → Los registros DS del padre y las cachés recursivas aún pueden depender de la cadena antigua → Mantén cadenas solapadas hasta que se superen las comprobaciones de validación y TTL.
• Desactivar DNSSEC globalmente como mitigación → La resolución se restablece a costa de la autenticación → Restaura primero una cadena válida conocida; acota, limita en el tiempo, aprueba y revierte cualquier excepción.
• Reducir el TTL tras la publicación → Las respuestas en caché continúan usando el TTL que recibieron originalmente → Planifica el TTL antes de la migración y mantén el endpoint antiguo compatible durante los incidentes.
• Probar únicamente dig y no el producto → La nueva IP aún puede tener fallos de certificados, enrutamiento o configuración → Verifica la resolución, TLS, las API críticas y las tasas de error de los usuarios.
• Probar solo un firmante → Las rutas de producción con múltiples nodos o múltiples HSM pueden generar resultados diferentes → Prueba la topología real y compara cada nodo de firma.

Preguntas de seguimiento y cómo responderlas

Pregunta de seguimiento 1: ¿Cómo distinguir rápidamente entre NXDOMAIN, una respuesta vacía y SERVFAIL?

Inspecciona el RCODE y la sección Authority. NXDOMAIN afirma que el nombre consultado no existe. NOERROR con una sección Answer vacía puede significar que el nombre existe sin el tipo solicitado, habitualmente con un SOA. SERVFAIL indica que el servidor no pudo producir un resultado aceptable; datos DNSSEC bogus, timeouts en el upstream, fallos de delegación y errores internos pueden causarlo. Determina qué capa produjo la respuesta y si una respuesta negativa tiene evidencia autenticada de denegación en lugar de confiar en el mensaje del navegador.

Pregunta de seguimiento 2: ¿Por qué algunos resolvers tienen éxito mientras otros fallan?

Compara si validan DNSSEC, qué RRset tienen en caché, cuándo expira, sus servidores upstream, sus relojes y sus políticas locales. Un resolver exitoso podría seguir sirviendo una caché válida previa al rollover o podría no validar DNSSEC. Un resolver que falla puede haberse actualizado y descubierto la cadena rota. La diversidad de resolvers es una pista; el comportamiento de CD/AD, los registros sin procesar y la antigüedad de la caché completan la atribución.

Pregunta de seguimiento 3: ¿Puede el vaciado de caché restablecer a todos los usuarios de inmediato?

Un operador solo puede purgar los navegadores, sistemas operativos o resolvers recursivos que controla. Los resolvers y endpoints externos respetan el TTL que ya recibieron, y el propietario de un dominio no dispone de una API de vaciado global. Restaurar una cadena firmada válida conocida mientras se mantiene compatible el endpoint antiguo cubre tanto las consultas frías como a los clientes con respuestas antiguas. La reducción del TTL previa a la migración solo funciona si se realiza con suficiente antelación para que el TTL anterior expire.

Pregunta de seguimiento 4: ¿En qué se diferencian los límites de rollover de KSK y ZSK?

Una implementación común utiliza una KSK para firmar el RRset de DNSKEY y una ZSK para firmar RRsets de negocio como A y AAAA. El rollover de KSK cruza el límite del DS del padre y, por tanto, diferentes organizaciones y cachés. El rollover de ZSK suele estar contenido dentro de la zona hija, pero aún requiere validez solapada de DNSKEY y RRSIG. Los proveedores pueden emplear diferentes modelos de claves, por lo que se debe deducir la respuesta a partir de los flags reales de DNSKEY, los firmantes y el procedimiento documentado en lugar de aplicar etiquetas mecánicamente.

Pregunta de seguimiento 5: ¿Qué release gates añadirías al rollover de DNSSEC?

Ejecuta el rollover en un entorno de preproducción con una topología equivalente a producción y demuestra que cada firmante produce salidas mutuamente válidas. Antes del lanzamiento, comprueba el DS del padre, la DNSKEY hija, los algoritmos admitidos, el inicio/expiración de RRSIG, el serial SOA y la consistencia de las autoridades; luego, ejecuta consultas frías a través de al menos dos validadores independientes. Las alertas necesitan un responsable asignado, una ruta de escalado y un procedimiento de rollback ensayado. Inyecta firmas expiradas, claves faltantes e inconsistencias entre nodos para demostrar que el incidente será detectado y gestionado.