Una migración de servidores de nombres puede parecer correcta en todos los paneles de control y, aun así, dejar un sitio web inaccesible. El dominio está activo, sus nuevos servidores de nombres autoritativos devuelven la dirección esperada y el servidor web no ha cambiado. Sin embargo, los resolutores DNS que realizan validación devuelven SERVFAIL. La causa suele estar en una delegación DNSSEC que todavía confía en la clave de firma del proveedor DNS anterior.
En el incidente analizado, las consultas normales fallaban, mientras que las mismas consultas tenían éxito al omitir la validación DNSSEC. La zona superior seguía publicando un registro DS antiguo, pero la nueva zona autoritativa inicialmente no estaba firmada. Publicar una clave coincidente y firmar la nueva zona permitió recuperar las respuestas validadas en los resolutores examinados. La lección principal no es que deba desactivarse DNSSEC, sino que cambiar los servidores de nombres y migrar la cadena de confianza de DNSSEC son operaciones distintas.
Por qué unos registros A correctos pueden seguir provocando SERVFAIL
DNS responde a dos preguntas diferentes. Un registro A indica a un resolutor qué dirección IPv4 corresponde a un nombre. DNSSEC permite que un resolutor con validación determine si puede confiar en la respuesta. Que los datos de dirección sean correctos no significa automáticamente que la cadena de confianza de DNSSEC sea válida.
En un dominio firmado, la cadena parte de una zona superior de confianza y pasa por un registro DS (Delegation Signer) hasta llegar a una DNSKEY en la zona hija. Esta última publica firmas (registros RRSIG) sobre sus datos DNS. El registro DS contiene un resumen criptográfico que identifica una DNSKEY autorizada; no es un registro A, una copia de la clave privada ni una opción de configuración dentro de un editor habitual de archivos de zona.
Después de cambiar los servidores de nombres autoritativos, la zona superior puede seguir publicando un registro DS asociado con el firmante anterior. Si la nueva zona no dispone de la DNSKEY correspondiente ni de las firmas necesarias, un resolutor con validación no puede completar la cadena de confianza. Normalmente considera que la respuesta no es válida y devuelve SERVFAIL en lugar de una dirección sin verificar.
Esto es distinto de una interrupción del servicio HTTP. Es posible que la solicitud ni siquiera llegue al servidor web. También es diferente de un certificado TLS caducado: DNSSEC valida los datos DNS, mientras que HTTPS protege una conexión posterior entre el navegador y el servidor.
La prueba que permite distinguir un problema de DNSSEC de un registro inexistente
La prueba más reveladora consiste en consultar dos veces el mismo nombre utilizando el mismo resolutor. Primero, realiza una consulta normal y examina su estado, no solo la respuesta:
dig example.com A +noall +comments +answerDespués, repite la consulta con el bit CD (Checking Disabled, desactivación de la comprobación DNSSEC) activado:
dig example.com A +cdflag +noall +comments +answerEn el fallo observado, la consulta normal devolvía SERVFAIL, mientras que la consulta con el bit CD devolvía el registro A esperado. Esta diferencia apuntaba claramente a un problema de validación DNSSEC, en lugar de a la ausencia de un registro DNS o a una aplicación que no respondía. La opción +cdflag solicita a un resolutor recursivo compatible que no realice su validación DNSSEC habitual para esa consulta. Es una herramienta de diagnóstico, no una solución aplicable desde el navegador ni una forma de desactivar DNSSEC para los visitantes.
No saques conclusiones precipitadas de una respuesta vacía obtenida con +short. Tanto la ausencia de una respuesta como un error SERVFAIL pueden aparecer como una salida vacía con ese formato. Durante el diagnóstico, conserva +comments para que sigan siendo visibles estados como status: SERVFAIL y status: NOERROR.
La comparación con el bit CD no identifica por sí sola qué parte de DNSSEC ha fallado; indica dónde investigar a continuación. Un resolutor también podría experimentar un error transitorio en un servidor anterior de la cadena de resolución, por lo que conviene repetir la prueba cuando sea necesario e inspeccionar la delegación de la zona superior.
Inspecciona el registro DS de la zona superior, no solo el editor DNS
Comprueba si existen registros DS para el dominio:
dig example.com DS +noall +comments +answerPara obtener una visión más completa de la ruta de delegación, consulta directamente la jerarquía DNS:
dig +trace example.com DSEl servidor de nombres autoritativo exacto de la zona superior depende del dominio de nivel superior. Lo importante es el conjunto de registros DS publicado por la zona superior, no únicamente el resumen mostrado en el panel del proveedor DNS. Una transferencia de registrador puede realizarse sin cambiar los servidores de nombres, y estos pueden cambiarse sin transferir el dominio a otro registrador. En cualquiera de los casos, los registros DS de la zona superior deben seguir siendo compatibles con la zona autoritativa activa.
Un registro DS tiene cuatro campos importantes: identificador de clave, algoritmo, tipo de resumen criptográfico y resumen criptográfico. El identificador de clave es una referencia útil para diagnosticar problemas, pero por sí solo no demuestra que una DNSKEY coincida. La información del resumen y del algoritmo también debe corresponder a una clave que realmente esté sirviendo la zona autoritativa.
El estado decisivo en este caso era sencillo: la zona superior seguía anunciando la información de confianza DNSSEC anterior, mientras que la nueva zona autoritativa indicaba que la firma estaba desactivada. Los registros A existían y podían obtenerse cuando se omitía la validación. Cambiar la configuración de la aplicación o editar repetidamente el mismo registro A no habría corregido esa incompatibilidad.
Dos formas de restaurar una delegación DNSSEC incorrecta
Existen dos estrategias legítimas de recuperación. Ambas resuelven la misma incompatibilidad en la cadena de confianza, pero tienen consecuencias operativas diferentes. Elige una de manera deliberada y evita alternar entre ellas sin un criterio claro.
Opción 1: eliminar el DS obsoleto y mantener temporalmente la zona sin firmar
Solicita al registrador actual, o utiliza su interfaz de administración DNSSEC compatible, que elimine el registro DS obsoleto de la zona superior. Una vez que esta deja de declarar una delegación segura, los resolutores con validación pueden considerar que una zona hija sin firmar es insegura, en lugar de inválida. DNS sigue funcionando, pero la autenticación DNSSEC del dominio queda temporalmente deshabilitada.
Esta suele ser la opción de emergencia más sencilla, siempre que exista una forma fiable de modificar el conjunto de registros DS de la zona superior. Mantén estable la configuración de firma existente hasta que el DS anterior haya caducado en las cachés de los resolutores recursivos. Eliminar el DS desde un panel de control no constituye, por sí solo, una prueba suficiente: verifica externamente el registro de la zona superior y ten en cuenta su TTL. HTTPS sigue siendo independiente de la configuración DNSSEC. La transición temporal a una zona sin firmar también se describe en RFC 8078.
Opción 2: firmar la nueva zona y publicar un DS coincidente
La alternativa consiste en activar DNSSEC en el nuevo proveedor de DNS autoritativo, generar el material criptográfico DNSKEY, firmar la zona y publicar el registro DS correspondiente en la zona superior. De ese modo, un resolutor con validación puede establecer una ruta de confianza hasta la nueva DNSKEY y validar el registro A.
Esta fue la vía de recuperación observada realmente. La interfaz de administración DNS indicó que había generado claves, firmado la zona y publicado un nuevo DS. Posteriormente, una consulta a la zona superior mostró el nuevo DS junto al anterior. Las consultas recursivas con validación empezaron a devolver el registro A esperado; una prueba posterior también devolvió NOERROR con el indicador ad activado, lo que señalaba que ese resolutor había autenticado los datos.
El orden importa: un DS publicado solo resulta útil si la DNSKEY correspondiente y las firmas válidas ya están disponibles en el servicio DNS autoritativo. Que un panel de control muestre «publicado» no sustituye una verificación externa. Los registros DS, DNSKEY, RRSIG y NS almacenados en caché pueden hacer que distintos resolutores se recuperen en momentos diferentes.
Por qué dos registros DS no necesariamente mantenían el sitio inaccesible
Un resultado sorprendente fue que la zona superior contenía temporalmente tanto un DS obsoleto como otro nuevo y válido, pero la validación DNSSEC tenía éxito. No hay contradicción. Un conjunto de registros DS puede contener varios registros, como suele ocurrir durante las transiciones de claves. Un validador no exige que todos los registros DS identifiquen una clave que siga siendo utilizable; necesita una ruta de autenticación válida a través de un DS aplicable hasta una DNSKEY y unas firmas válidas. RFC 6840 aclara que los validadores deben aceptar una única ruta válida.
Eso no significa que sea conveniente conservar indefinidamente las claves obsoletas. Un DS antiguo añade ambigüedad operativa y debería eliminarse cuando se haya verificado la nueva cadena de confianza. Sin embargo, esa limpieza es una tarea de mantenimiento, no una razón para ejecutar otro restablecimiento arriesgado de DNSSEC mientras las consultas validadas ya funcionan.
Aquí existe una trampa especialmente peligrosa en los paneles de control: una acción denominada «anular la publicación de DS en caso de emergencia» puede significar eliminar todos los registros DS, incluido el nuevo que funciona. Del mismo modo, desactivar la firma de la zona mientras sigue publicado un DS puede reproducir inmediatamente la interrupción del servicio. Ninguna de esas acciones equivale a eliminar un único registro DS obsoleto. Si la interfaz no permite seleccionar un registro concreto, utiliza un procedimiento de modificación selectiva admitido por el registrador en lugar de un restablecimiento general.
Cómo cambiar los servidores de nombres autoritativos de forma segura
La secuencia más segura depende de si los proveedores DNS antiguo y nuevo pueden coordinar las claves. Para una migración convencional que utilice un intervalo temporal sin firma, el siguiente orden evita la incompatibilidad observada en este incidente:
- Prepara primero la zona de destino. Copia los registros A, AAAA, CNAME, MX, TXT y cualquier otro que sea necesario. Prueba directamente los nuevos servidores de nombres autoritativos antes de cambiar la delegación.
- Inspecciona DNSSEC en la zona superior. Comprueba si existen registros DS e identifica quién puede modificarlos. Hazlo incluso si nunca has activado DNSSEC manualmente, ya que algunos servicios DNS automatizan la firma.
- Elimina el DS antiguo mientras la zona anterior firmada sigue funcionando. Confirma el cambio en la zona superior autoritativa y espera el tiempo suficiente para que caduquen los datos DS almacenados previamente en caché. El tiempo de espera depende de los TTL observados, no de un número fijo y universal de minutos.
- Cambia la delegación de los servidores de nombres. Mantén disponible el servicio autoritativo anterior mientras las delegaciones NS almacenadas en caché puedan seguir apuntando a él. Ten en cuenta los TTL de los registros NS de la zona superior y comprueba qué servidores están utilizando realmente los distintos resolutores.
- Decide si quieres volver a activar DNSSEC. Si el nuevo servicio debe permanecer sin firmar, no publiques ningún DS. Si debe estar firmado, comprueba que la nueva DNSKEY y las firmas se están sirviendo correctamente antes de publicar el DS correspondiente. Coordina este paso con las cachés que todavía puedan contener los servidores NS antiguos para evitar otra incompatibilidad de validación.
- Valida de forma independiente. Comprueba el DS de la zona superior, la DNSKEY autoritativa, la resolución recursiva normal y el resultado de autenticación de los resolutores con validación.
Si es necesario mantener la protección DNSSEC de forma continua, resulta preferible una rotación de claves coordinada explícitamente o una transición con varios firmantes, en lugar de un intervalo sin firma. Para ello, ambos proveedores DNS deben admitir la configuración necesaria de claves y firmas; copiar simplemente el resumen del DS antiguo al nuevo proveedor no constituye una rotación de claves.
Lista breve de comprobaciones después de la migración
Después de cualquier cambio relacionado con DNSSEC, comprueba tanto los registros DNS como la evidencia de que los resolutores los aceptan:
dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answerUtiliza un resolutor recursivo que realice validación para comprobar las respuestas autenticadas. En su respuesta, NOERROR junto con el registro A esperado significa que la resolución ha tenido éxito; la presencia adicional del indicador ad señala que el resolutor ha autenticado la respuesta según su política DNSSEC. La ausencia del indicador ad no demuestra por sí sola que exista un fallo, porque las capacidades, políticas e indicadores de consulta de los resolutores pueden variar. Si las consultas DNSKEY fallan a través de un resolutor con validación durante una interrupción, consulta directamente el servicio DNS autoritativo activo como parte de la investigación.
No te detengas después de obtener una única respuesta correcta de un resolutor. Durante un tiempo, distintas cachés pueden contener delegaciones y claves diferentes. Actualiza también cualquier solicitud de asistencia técnica que siga abierta: una instrucción anterior de eliminar todos los registros DS se vuelve peligrosa una vez que se ha publicado un nuevo DS funcional. La comunicación de seguimiento debe indicar explícitamente que se conserve la clave activa y, si es necesario, solicitar la eliminación únicamente del registro obsoleto.
El fallo no se debió a una dirección incorrecta del servidor web. Se produjo porque cambió el lugar desde el que se servían las respuestas DNS sin ajustar previamente la información de confianza que indicaba a los resolutores qué respuestas debían aceptar. Por tanto, la pregunta fundamental antes de cambiar cualquier delegación de servidores de nombres es: ¿Qué registros DS publica la zona superior y podrán validarse mediante las DNSKEY y firmas del servicio de destino?