Resumen

  • RFC 8901 es un documento Informativo de consenso del IETF, no una norma obligatoria ni prueba de que un proveedor concreto implemente DNSSEC con varios firmantes.
  • En sus dos modelos, el RRset DNSKEY de cada proveedor contiene los ZSK activos de todos. Sin ello, un resolutor puede guardar las claves de A, recibir durante el failover una firma de B y rechazarla.
  • El propietario de la zona coordina el intercambio de claves, la relación entre KSK y DS del padre, los algoritmos comunes y el calendario de rotación antes de la avería. El segundo proveedor solo es una ruta potencial mientras falte esa evidencia.

La autoridad respondió; la cadena no llegó

Una zona se sirve desde dos proveedores independientes. Un resolutor validador sigue la delegación segura, obtiene de A el RRset DNSKEY, lo autentica mediante el DS del padre y lo conserva en caché. Más tarde, mientras ese estado sigue vigente, A deja de ser alcanzable. El resolutor elige B, que devuelve el registro solicitado con una RRSIG producida por su propio ZSK.

B está en línea. La respuesta puede seguir siendo inútil: si el DNSKEY almacenado desde A no incluye el ZSK activo de B, el resolutor carece de una clave pública autenticada para comprobar la firma. Puede consultar otro servidor, asumir más latencia o agotar reintentos antes de que venza el cliente. RFC 8901 no cambia esa conducta; exige que los firmantes preparen una vista de claves que permita a la validación normal sobrevivir al cambio.

La diversidad de redes, contratos y nombres NS demuestra rutas posibles de disponibilidad. No demuestra que una firma de B sea verificable con el estado recibido de A. La redundancia se completa cuando también cruza el límite criptográfico.

Dos modelos, un mismo invariante

En el modelo 1, el propietario mantiene un KSK común y administra el DS del padre. Cada proveedor conserva su ZSK. El propietario reúne las claves públicas, compone un RRset DNSKEY combinado, lo firma con el KSK y lo distribuye a todos. Aunque no cambie ninguna clave, debe renovar la RRSIG del conjunto antes de que expire.

El padre tiene una entrada común y todos sirven el mismo objeto firmado. A cambio, la custodia del KSK, la nueva firma periódica y la distribución por API forman un control crítico. Una copia antigua en un solo proveedor divide la realidad operativa.

En el modelo 2, cada proveedor posee su KSK y su ZSK. Cada uno importa los ZSK públicos de los demás y firma el RRset resultante con su propio KSK. El padre publica DS para cada KSK. Así, el resolutor puede autenticar la vista obtenida de cualquiera de los dos.

La custodia privada está distribuida, pero crece el estado compartido. Rotar el KSK de A cambia su camino en el DS del padre. Rotar su ZSK cambia el DNSKEY que B debe publicar. La independencia de secretos no elimina la dependencia de datos públicos coordinados.

La rotación es una transacción distribuida

Con el modelo 1, A no activa inmediatamente un ZSK nuevo. El propietario lo recoge, lo inserta en el conjunto combinado, firma y despliega ese conjunto en todos los proveedores. La activación espera la propagación y el TTL de DNSKEY; el retiro espera a que los datos firmados por la clave anterior y sus TTL ya no dependan de ella. Un cambio de KSK también atraviesa el DS del padre.

Con el modelo 2, A puede firmar su propio DNSKEY, pero entrega el nuevo ZSK al propietario para que B lo importe. A espera la importación, la propagación en todos los servidores y el TTL antes de usarlo en datos ordinarios. El retiro recorre la coordinación en sentido inverso.

Por eso «clave creada» o «API 200» no son recibos de continuidad. La secuencia defendible registra exportación, aceptación, importación en cada proveedor, publicación en cada superficie autoritativa, paso de TTL, validación independiente mediante respuestas de A y B y, solo después, activación o retiro.

Algoritmos y ausencia autenticada

Los proveedores necesitan un algoritmo de firma común o el mismo conjunto de algoritmos. Si DNSKEY anuncia varios, las reglas de DNSSEC exigen las firmas correspondientes en los RRsets. Dos opciones incompatibles no se corrigen por el hecho de pertenecer a empresas distintas.

Las pruebas NSEC o NSEC3 viajan con la respuesta negativa y permiten cierta diversidad técnica. Sin embargo, mezclar NSEC con NSEC3 anula la protección de NSEC3 frente a la enumeración sencilla; configuraciones permanentes distintas también pueden hacer menos eficiente la caché negativa. RFC 8901 prefiere un método único y limita las diferencias inevitables.

Un ensayo que solo pregunta por A o AAAA no cubre este plano. Una respuesta positiva puede validar mientras una inexistencia de nombre o tipo expone otra firma y otro estado de caché.

Lo que el documento no prueba

RFC 8901 es Informativo. No demuestra soporte de una API, una implantación concreta, una avería medida, ganancia de disponibilidad ni adopción. DNSSEC tampoco prueba mandato comercial, salud de la aplicación o que el tráfico haya cambiado de proveedor; prueba una relación criptográfica acotada para los datos observados.

La conclusión operativa es precisa: comprar un segundo proveedor reduce una dependencia únicamente cuando el propietario puede reproducir antes del incidente la vista conjunta de claves, los DS, los algoritmos y la línea temporal de rotación.

Fuentes