Tema representativo de entrevista

Entrevista de diseño de sistemas: ¿Cómo construirías un plano de control auditable para la rotación de claves DNSSEC?

Diseño de sistemasDifícil
Equipo editorial de Offer.ccPublicado Actualizado

Pregunta

Operas una plataforma DNS multiinquilino y necesitas un plano de control para la rotación de claves DNSSEC. ¿Cómo preservas el orden de DS, DNSKEY y RRSIG, te recuperas de fallas y conservas la evidencia de auditoría?

Planteamiento

Diseña un plano de control para la rotación de claves DNSSEC para una plataforma que aloja decenas de miles de zonas firmadas. Debe coordinar registros DS de registradores, registros DNSKEY/RRSIG de DNS autoritativo y aprobaciones de inquilinos sin exponer a los resolutores validadores a una cadena rota.

Escenario y restricciones

Los tiempos de vida de KSK y ZSK difieren, las API de los registradores tienen demoras y admiten reintentos, y los nodos autoritativos abarcan múltiples regiones. El plano de control necesita reintentos idempotentes, pausa por inquilino, transiciones de estado auditables y un comportamiento que falle de forma segura (fail-closed) cuando un paso sea incierto.

Qué evalúa esto

El núcleo son las máquinas de estado, las invariantes de tiempo, la orquestación de efectos secundarios externos y la observabilidad. Las respuestas sólidas distinguen la prepublicación de DNSKEY, la publicación de DS, el retiro de claves antiguas y la superposición de firmas; generar una clave por sí sola no constituye una rotación.

Enfoque de referencia

Persiste una máquina de estados por zona: observe, prepublish, ds-submit, ds-visible, sign-with-both, retire-old y verify. Registra la versión deseada, el token de operación, el margen de TTL y la instantánea de evidencia en cada transición. Publica la nueva DNSKEY en todos los nodos autoritativos y espera su TTL, luego envía el DS a través del registrador. Una vez que el DS principal sea visible a través de varios resolutores recursivos, firma con ambas claves durante una ventana de seguridad, y solo entonces elimina el DS y la DNSKEY antiguos.

Ejecuta una zona a la vez bajo un arrendamiento (lease). Las llamadas externas utilizan claves de idempotencia y retroceso exponencial (exponential backoff). Congela una zona ante SERVFAIL, discrepancias entre DS/DNSKEY o RRSIG vencidas; conserva el material antiguo y solicita aprobación humana.

Detalles críticos

La base de datos almacena el estado deseado, mientras que las consultas DNS y las relecturas del registrador son las fuentes de la verdad; los conflictos no deben sobrescribirse a ciegas. Los tiempos incluyen los TTL autoritativos y recursivos, la validez de la firma y el margen de propagación. Mantén las claves privadas en un almacenamiento KMS controlado y registra huellas digitales, key tags, versiones y actores en lugar del material privado.

Errores comunes

Modificar un objeto de registrador de forma concurrente entre inquilinos; verificar solo los nodos autoritativos y no el DS principal; eliminar la clave antigua inmediatamente después de un paso fallido; tratar los reintentos de cola como idempotencia; y omitir rutas de pausa o de intervención humana.

Rúbrica de evaluación

Las respuestas sólidas definen los límites entre el plano de control, el DNS autoritativo, el registrador, los resolutores validadores y el almacenamiento de auditoría; establecen al menos tres invariantes de seguridad; y especifican condiciones de entrada, salida y reversión para cada estado. También nombran métricas de tasa de éxito, SERVFAIL, latencia de propagación y arrendamientos bloqueados (stuck-lease).

Preguntas de seguimiento

¿Por qué la publicación de DS normalmente ocurre después de la prepublicación de DNSKEY?

La prepublicación permite que los nodos autoritativos y las cachés adquieran primero la nueva DNSKEY. El DS principal puede entonces apuntar a una clave que los validadores puedan recuperar, reduciendo la ventana en la que el DS es visible pero la DNSKEY falta.

¿Cómo reintentas cuando una llamada al registrador agota el tiempo de espera pero puede haber tenido éxito?

Lee el DS actual del registrador utilizando la versión de la zona y el token de idempotencia, luego decide si reintentar. No envíes una segunda mutación desconocida basándote únicamente en un tiempo de espera agotado.

¿Cuándo puede el sistema eliminar automáticamente el DS antiguo?

Solo después de que el nuevo DS permanezca visible en el conjunto de resolutores recursivos objetivo, la validación de RRSIG sea exitosa y las ventanas de TTL y de firma cumplan con la política. De lo contrario, la zona permanece congelada.

Fuentes públicas

Preguntas relacionadas

Herramienta de entrevista relacionada

Usa Resolver para una respuesta de diseño de sistemas

Aclara primero los requisitos y luego avanza a través de la escala, la arquitectura, la elección de componentes y las compensaciones (trade-offs).

Ver la herramienta